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Abstract: The medium access control (MAC) and physical characteristics for wireless local area 
networks (LANs) are specified in this standard, part of a series of standards for local and metropol- 
itan area networks. The medium access control unit in this standard is designed to support physi- 
cal layer units as they may be adopted dependent on the availability of spectrum. This standard 
contains three physical layer units: two radio units, both operating in the 2400-2500 MHz band, 
and one baseband infrared unit. One radio unit employes the frequency-hopping spread spectrum 
technique, and the other employs the direct sequence spread spectrum technique. 
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International Standard ISO/IEC 8802-11: 1999(E) 



ISO (the International Organization for Standardization) and IEC (the International Electrotechnical 
Commission) form the specialized system for worldwide standardization. National bodies that are 
members of ISO or IEC participate in the development of International Standards through technical 
committees established by the respective organization to deal with particular fields of technical activity. 
ISO and IEC technical committees collaborate in fields of mutual interest. Other international 
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the 
work. 

In the field of information technology, ISO and IEC have established a joint technical committee. 
ISO/IEC JTC I. Draft International Standards adopted by the joint technical committee are circulated to 
national bodies for voting. Publication as an International Standard requires approval by at least 75 % of 
the national bodies casting a vote. 

International Standard ISO/IEC 8802-1 1 was prepared by. Joint Technical Committee ISO/IEC JTC 1, 
Information technology, Subcommittee SC 6, Telecommunications and information exchange between 
systems. 

ISO/IEC 8802 consists of the following parts, under the general title Information technology — 
Telecommunications and information exchange between systems — Local and metropolitan area 
networks — Specific requirements: 

— Part I: Overview of Local Area Network Standards 

— Part 2: Logical link control 

— Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and 
physical layer specifications 

— Part 4: Token-passing bus access method and physical layer specifications 

— Part 5: Token ring access method and physical layer specifications 

— Part 6: Distributed Queue Dual Bus (DQDB) access method and physical layer specifications 

— Part 7: Slotted ring access method and physical layer specification 

— Part 9: Integrated Services (IS) LAN Interface at the Medium Access Control (MAC) and Phvsical 
(PHY) Layers 

— Part 1 1: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications 

— Part 12: Demand-Priority access method, physical layer and repeater specifications 

Annexes A. C and D form a normative part of this part of ISO/IEC 8802. Annexes B and E are for 
information only. 
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Foreword to International Standard ISO/IEC 8802-11: 1999 



This International Standard is part of a family of International Standards for Local and. Metropolitan Area 
Networks. The relationship between this International Standard, which provides extensions to the behavior 
of ISO/IEC 1 0038, and the other members of the family is shown below. (The numbers in the figure refer to 
ISO/IEC Standard numbers.) 
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This family of International Standards deals with the Physical and Data Link layers as defined by the ISO 
Open Systems Interconnection (OSI) Basic Reference Model (ISO/IEC 7498- 1: 1994). The access standards 
define seven types of medium access technologies and associated physical media, each appropriate for 
particular applications or system objectives. Other types are under investigation. 

The International Standards defining the access technologies are as follows: 

a) ISO/IEC 8802-3, utilizing carrier sense multiple access with collision detection (CSMA/CD) as the 
access method. 

b) ISO/IEC 8802-4, utilizing token passing bus as the access method. 

c) ISO/IEC 8802-5, utilizing token passing ring as the access method. 

d) ISO/IEC 8802-6, utilizing distributed queuing dual bus as the access method. 

e) ISO/IEC 8802-9, a unified access method offering integrated services for backbone networks. 

0 ISO/IEC 8802- 1 1 , a wireless LAN utilizing carrier sense multiple access with collision avoidance 

(CSMA/CA) as the access method, 
g) ISO/IEC 8802*12, utilizing Demand Priority as the access method. 

ISO/IEC TR 8802-1 , Overview of Local Area Network Standards, provides an overview of the series of ISO/ 
IEC 8802 standards. 

ISO/IEC 8802-2, Logical Link Control, is used in conjunction with the medium access standards to provide 
the data link layer service to network layer protocols. 

ISO/IEC 15802-1, Medium Access Control (MAC) service definition, specifies the characteristics of the 
common MAC Service provided by all IEEE 802 LAN MACs. The service is defined in terms of primitives 
that can be passed between peer service users, their parameters, their interrelationship and valid sequences, 
and the associated events of the service. 

ISO/IEC 15802-2, LAN/MAN Management, defines an OSI management-compatible architecture, and 
services and protocol elements for use in a LAN/MAN environment for performing remote management. 

ISO/IEC 10038, Media Access Control (MAC) bridges, specifies an architecture and protocol for the intercon- 
nection of IEEE 802 LANs below the level of the logical link control protocol (to be renumbered 15802-3). 

ISO/IEC 15802*4, System Load Protocol, specifies a set of services and protocol for those aspects of manage- 
ment concerned with the loading of systems on IEEE 802 LANs. 

ISO/IEC 15802-5, Remote Media Access Control (MAC) bridging, specifies extensions for the interconnec- 
tion, using non-LAN communication technologies, of geographically separated IEEE 802 LANs below the 
level of the logical link control protocol. 



Copyright © 1999 IEEE. All rights reserved. 



iii 



ANSI/IEEE Std 802.11, 1999 Edition 

IEEE Standards documents are developed within the Technical Committees of the IEEE Societies and the 
Standards Coordinating Committees of the IEEE Standards Board. Members of the committees serve volun- 
tarily and without compensation. They are not necessarily members of the Institute. The standards developed 
within IEEE represent a consensus of the broad expertise on the subject within the Institute as wei! as those 
activities outside of IEEE that have expressed an interest in participating in the development of the standard. 

Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there 
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to 
the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and 
issued is subject to change brought about through developments in the state of the art and comments 
received from users of the standard. Every IEEE Standard is subjected to review at least every five years for 
revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is rea- 
sonable to conclude that its contents, although still of some value, do not wholly reflect the present state of 
the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. 

Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership 
affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of 
text, together with appropriate supporting comments. 

Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they 
relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the 
Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of 
all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a 
balance of interests. For this reason IEEE and the members of its technical committees are not able to pro- 
vide an instant response to interpretation requests except in those cases where the matter has previously 
received formal consideration. 

Comments on standards and requests for interpretations should be addressed to: 

Secretary, IEEE Standards Board 
445 Hoes Lane 
P.O. Box 1331 
Piscataway, NJ 08855-1331 
USA 



Note: Attention is called to the possibility that implementation of this standard may require use of sub- 
ject matter covered by patent rights. By publication of this standard, no position is taken with respect to 
the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible 
for identifying all patents for which a license may be required by an IEEE standard or for conducting 
inquiries into the legal validity or scope of those patents that are brought to its attention. 

The patent holder has, however, filed a statement of assurance that it will grant a license under these 
rights without compensation or under reasonable rates and nondiscriminatory, reasonable terms and 
conditions to all applicants desiring to obtain such a license. The IEEE makes no representation as to 
the reasonableness of rates and/or terms and conditions of the license agreement offered by the patent 
holder. Contact information may be obtained from the IEEE Standards Department. 



Authorization to photocopy portions of any individual standard for internal or personal use is granted by the 
Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright 
Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Cus- 
tomer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy 
portions of any individual standard for educational classroom use can also be obtained through the Copy- 
right Clearance Center. 
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Introduction to ANSI/IEEE Std 802.11, 1999 Edition 



(This introduction is not a part of ANSI/IEEE Std 802. 1 1, 1 999 Edition or of ISO/IEC 8802- I 1: 1999, but is included for information 
purpose only.) 

This standard is part of a family of standards for local and metropolitan area networks. The relationship 
between the standard and other members of the family is shown below. (The numbers in the figure refer to 
IEEE standard numbers.) 
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* Formerly IEEE Std 802.1A. 

This family of standards deals with the Physical and Data Link layers as defined by the Internationa! Organiza- 
tion for Standardization (ISO) Open Systems Interconnection (OSI) Basic Reference Model (ISO/IEC 7498- 
1: 1994). The access standards define seven types of medium access technologies and associated physical 
media, each appropriate for particular applications or system objectives. Other types are under investigation. 

The standards defining the access technologies are as follows: 



• IEEE Std 802 

• ANSI/IEEE Std 802. IB 
and 802. Ik 

[ISO/IEC 15802-2] 

• ANSI/IEEE Std 802. ID 
[ISO/IEC 15802-3] 

• ANSI/IEEE Std 802. IE 
[ISO/IEC 15802-4] 

• IEEE Std 802.-1 F 

• ANSI/IEEE Std 802. 1G 
[ISO/IEC 15802-5] 



ANSI/IEEE Std 802.2 
[ISO/IEC 8802-2] 



Overview and Architecture. This standard provides an overview to the family 
of IEEE 802 Standards. 

LAN/MAN Management. Defines an OSI management-compatible architec- 
ture, and services and protocol elements for use in a LAN/MAN environment 
for performing remote management. 

Media Access Control (MAC) Bridges. Specifies an architecture and protocol 
for the interconnection of IEEE 802 LANs below the MAC service boundary. 

System Load Protocol. Specifies a set of services and protocol for those 
aspects of management concerned with the loading of systems on IEEE 802 
LANs. 

Common Definitions and Procedures for IEEE HO 2 Management Information 

Remote Media Access Control (MAC) Bridging, Specifies extensions for the 
interconnection; using non-LAN communication technologies, of geographi- 
cally separated IEEE 802 LANs below the level of the logical link control 
protocol. 

Logical Link Control 
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• ANSI/IEEE Std 802.3 CSMA/CD Access Method and Physical Layer Specifications 
[ISO/IEC 8802-3] 

• ANSI/IEEE Std 802.4 Token Passing Bus Access Method and Physical Layer Specifications 
[ISO/IEC 8802-4] 

• ANSI/I EEE Std 802.5 Token Ring Access Method and Physical Layer Specifications 
[ISO/IEC 8802-5] 

• ANSI/IEEE Std 802.6 Distributed Queue Dual Bus Access Method and Physical Layer Specifica- 
[ISO/IEC 8802-6] Hons 

• ANSI/I EEE Std 802.9 Integrated Services (IS) LAN Interface at the Medium Access Control (MAC) 
[ISO/IEC 8802-9] and Physical (PHY) Layers 

• ANSIAEEE Std 802. 1 0 Interoperable LAN/MAN Security 

• IEEE Std 802. 1 1 Wireless LAN Medium Access Control (MAC) and Physical Layer Specifi- 
[ISO/IEC DIS 8802-1 1] cations 

• ANSI/IEEE Std 802. 1 2 Demand Priority Access Method, Physical Layer and Repeater Specifica- 
[ISO/1EC DIS 8802-12] tions 

In addition to the family of standards, the following is a recommended practice for a common Physical 
Layer technology: 

• IEEE Std 802.7 IEEE Recommended Practice for Broadband Local Area Networks 
The following additional working group has authorized standards projects under development: 

• IEEE 802. 1 4 Standard Protocol for Cable-TV Based Broadband Communication Network 

Conformance test methodology 

An additional standards series, identified by the number 1802, has been established to identify the 
conformance test methodology documents for the 802 family of standards. Thus the conformance test 
documents for 802.3 are numbered 1802.3. 

ANSI/IEEE Std 802.11, 1999 Edition [ISO/IEC 8802-11: 1999] 

This standard is a revision of IEEE Std 802.1 1-1 997. The Management Information Base according to OSI 
rules has been removed, many redundant management items have been removed, and Annex D has been 
completed with the Management Information Base according to SNMR Minor changes have been made 
throughout the document. 

This standard defines the protocol and compatible interconnection of data communication equipment via the 
"air", radio or infrared, in a local area network (LAN) using the carrier sense multiple access protocol with 
collision avoidance (CSMA/CA) medium sharing mechanism. The medium access control (MAC) supports 
operation under control of an access point as well as between independent stations. The protocol includes 
authentication, association, and reassociation services, an optional encryption/decryption procedure, power 
management to reduce power consumption in mobile stations, and a point coordination function for time- 
bounded transfer of data. The standard includes the definition of the management information base (MIB) 
using Abstract Syntax Notation 1 (ASN.I) and specifies the MAC protocol in a formal way, using the Speci- 



vi 



Copyright © 1999 IEEE. All rights reserved. 



fication and Description Language (SDL). Both ASN.I and SDL source code have been added on a floppy 
diskette. 

The infrared implementation of the PHY supports 1 Mbit/s data rate with an optional 2 Mbit/s extension. 
The radio implementations of the PHY specify either a frequency-hopping spread spectrum (FHSS) 
supporting i Mbit/s and an optional 2 Mbit/s data rate or a direct sequence spread spectrum (DSSS) 
supporting both 1 and 2 Mbit/s data rates. 

This standard contains state-of-the-art material. The area covered by this standard is undergoing evolution. 
Revisions are anticipated to this standard within the next few years to clarify existing material, to correct 
possible errors, and to incorporate new related material. Information on the current revision state of this and 
other IEEE 802 standards may be obtained from 

Secretary, IEEE Standards Board 
445 Hoes Lane 
P.O. Box 1331 

Piscataway, NJ 08855-1331 USA 
Participants 
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Information technology — 

Telecommunications and information exchange 
between systems — 

Local and metropolitan area networks — 
Specific requirements — 

Part 1 1 : Wireless LAN Medium Access 
Control (MAC) and Physical Layer 
(PHY) specifications 

1. Overview 

1.1 Scope 

The scope of this standard is to develop a medium access control (MAC) and physical layer (PHY) specifica- 
tion for wireless connectivity for fixed, portable, and moving stations within a local area. 

1.2 Purpose 

The purpose of this standard is to provide wireless connectivity to automatic machinery, equipment, or sta- 
tions that require rapid deployment, which may be portable or hand-held, or which may be mounted on mov- 
ing vehicles within a local area. This standard also offers regulatory bodies a means of standardizing access 
to one or more frequency bands for the purpose of local area communication. 

Specifically, this standard 

— Describes the functions and services required by an IEEE 802. 1 1 compliant device to operate within 
ad hoc and infrastructure networks as well as the aspects of station mobility (transition) within those 
networks* . • - . 

— Defines the MAC procedures to support the asynchronous MAC service data unit (MSDU) delivery 
services. 

— Defines several PHY signaling techniques and interface functions that are controlled by the IEEE 
802. 1 1 MAC. 

— Permits the operation of an IEEE 802. 1 1 conformant device within a wireless local area network 
(LAN) that may coexist with multiple overlapping IEEE 802.1 1 wireless LANs. 

— Describes the requirements and procedures to provide privacy of user information being transferred 
over the wireless medium (WM) and authentication of IEEE 802. 1 1 conformant devices. 
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ANSI/IEEE Std 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



2. Normative references 

The following standards contain provisions which, through references in this text, constitute provisions of 
this standard. At the time of publication, the editions indicated were valid. All standards are subject to revi- 
sion, and parties to agreements based on this standard are encouraged to investigate the possibility of apply- 
ing the most recent editions of the standards listed below. 

IEEE Std 802-1990, IEEE Standards for Local and Metropolitan Area Networks: Overview and Architec- 
ture. 1 

IEEE Std C95. 1-1991 (ReafT 1997), IEEE Standard Safety Levels with Respect to Human Exposure to 
Radio Frequency Electromagnetic Fields, 3 kHz to 300 GHz. 

ISO/IEC 7498-1: 1994, Information technology — Open Systems Interconnection — Basic Reference Model: 
The Basic Model. 2 

ISO/IEC 8802-2: 1998, Information technology — Telecommunications and information exchange between 
systems — Local and metropolitan area networks — Specific requirements — Part 2: Logical link control. 

ISO/IEC 8824-1: 1995, Information technology— Abstract Syntax Notation One (ASN.l): Specification of 
basic notation. 

ISO/IEC 8824-2: 1995, Information technology— Abstract Syntax Notation One (ASN.l): Information 
object specification. 

ISO/IEC 8824-3: 1995, Information technology— Abstract Syntax Notation One (ASN.l): Constraint speci- 
fication. 

ISO/IEC 8824-4: 1995, Information technology — Abstract Syntax Notation One (ASN.l): Parameterization 
of ASN.l specifications. 

ISO/IEC 8825-1: 1995, Information technology — ASN.l encoding rules: Specification of Basic Encoding 
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). 

ISO/IEC 8825-2: 1996, Information technology — ASN.l encoding rules: Specification of Packed Encoding 
Rules (PER). 

ISO/IEC 15802-1: 1995, Information technology — Telecommunications and information exchange between 
systems — Local and metropolitan area networks — Common specifications — Part 1 : Medium Access Control 
(MAC) service definition. 

ITU Radio Regulations, volumes 1-4. 3 

ITU-T Recommendation X.210 (11/93), Information technology — Open systems interconnection — Basic 
Reference Model: Conventions for the definition of OSI services (common text with ISO/IEC). 

ITU-T Recommendation Z.100 (03/93), CCITT specification and description language (SDL). 

ITU-T Recommendation Z J05 (03/95), SDL combined with ASN. 1 (SDL/ASN. 1). 



IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, 
NJ 08855- 133 l f USA (hup ://www. standards.ieee.org/). 

2 ISO and ISO/IEC publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembe, CH-121 1, Geneve 
20, Switzerland/Suisse (http://www.iso.ch/). They are also available in the United Stales from the Sales Department, American National 
Standards Institute, 1 1 West 42nd Street, 13th Floor, New York, NY 10036, USA (http://www.ansi.org/). 

3 ITU-T publications are available from the International Telecommunications Union, Place des Nations, CH- 1 2 1 1 , Geneva 20, Switzer- 
land/Suisse (http://www.itu.inl/). They are also available in the United States from the U.S. Department of Commerce, Technology 
Administration, National Technical Information Service (NTIS), Springfield, VA 22161, USA. 
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1W ^^^^ „ ISO/IEC 8802-11: 1999(E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.11, 1999 Edition 

3. Definitions 

3.1 access control: The prevention of unauthorized usage of resources. 

3.2 access point (AP): Any entity that has station functionality and provides access to the distribution ser- 
vices, via the wireless medium (WM) for associated stations. 

3.3 ad hoc network: A network composed solely of stations within mutual communication range of each 
other via the wireless medium (WM). An ad hoc network is typically created in a spontaneous manner. The 
principal distinguishing characteristic of an ad hoc network is its limited temporal and spatial extent. These 
limitations allow the act of creating and dissolving the ad hoc network to be sufficiently straightforward and 
convenient so as to be achievable by nontechnical users of the network facilities; i.e., no specialized "techni- 
cal skills" are required and little or no investment of time or additional resources is required beyond the sta- 
tions that are to participate in the ad hoc network. The term ad hoc is often used as slang to refer to an 
independent basic service set (IBSS). 

3.4 association: The service used to establish access point/station (AP/STA) mapping and enable STA invo- 
cation of the distribution system services (DSSs). 

3.5 authentication: The service used to establish the identity of one station as a member of the set of sta- 
tions authorized to associate with another station. 

3.6 basic service area (BSA): The conceptual area within which members of a basic service set (BSS) may , 
communicate. 

3.7 basic service set (BSS): A set of stations controlled by a single coordination function. 

3.8 basic service set (BSS) basic rate set: The set of data transfer rates that all the stations in a BSS will be 
capable of using to receive frames from the wireless medium (WM). The BSS basic rate set data rates are 
preset for all stations in the BSS. 

3.9 broadcast address: A unique multicast address that specifies all stations. 

3.10 channel: An instance of medium use for the purpose of passing protocol data units (PDUs) that may be 
used simultaneously, in the same volume of space, with other instances of medium use (on other channels) 
by other instances of the same physical layer (PHY), with an acceptably low frame error ratio due to mutual 
interference. Some PHYs provide only one channel, whereas others provide multiple channels. Examples of 
channel types are as shown in the following table: 



Single channel 


n-channel 


Narrowband radio- frequency (Rf ) channel 


Frequency division multiplexed channels 


Baseband infrared 


Direct sequence spread spectrum ( DSSS) with code divi- 
sion multiple access 



3.11 clear channel assessment (CCA) function: That logical function in the physical layer (PHY) that 
determines the current state of use of the wireless medium (WM). 

3.12 confidentiality: The property of information that is not made available or disclosed to unauthorized 
individuals, entities, or processes. 
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3.13 coordination function: The logical function that determines when a station operating within a basic 
service set (BSS) is permitted to transmit and may be able to receive protocol data units (PDUs) via the wire- 
less medium (WM). The coordination function within a BSS may have one point coordination function 
(PCF) and will have one distributed coordination function (DCF). 

3.14 coordination function poliabie: A station able to (i) respond to a coordination function poll with a 
data frame, if such a frame is queued and able to be generated, and (2) interpret acknowledgments in frames 
sent to or from the point coordinator. 

3.15 deauthentication: The service that voids an existing authentication relationship. 

3.16 directed address: See: unicast frame. 

3.17 disassociarion: The service that removes an existing association. 

3.18 distributed coordination function (DCF): A class of coordination function where the same coordination 
function logic is active in every station in the basic service set (BSS) whenever the network is in operation. 

3.19 distribution: The service that, by using association information, delivers medium access control 
(MAC) service data units (MSDUs) within the distribution system (DS). 

3.20 distribution system (DS): A system used to interconnect a set of basic service sets (BSSs) and inte- 
grated local area networks (LANs) to create an extended service set (ESS). 

3.21 distribution system medium (DSM): The medium or set of media used by a distribution system (DS) 
for communications between access points (APs) and portals of an extended service set (ESS). 

3.22 distribution system service (DSS): The set of services provided by the distribution system (DS) that 
enable the medium access control (MAC) to transport MAC service data units (MSDUs) between stations 
that are not in direct communication with each other over a single instance of the wireless medium ( WM). 
These services include transport of MSDUs between the access points (APs) of basic service sets (BSSs) 
within an extended service set (ESS), transport of MSDUs between portals and BSSs within an ESS, and 
transport of MSDUs between stations in the same BSS in cases where the MSDU has a multicast or broad- 
cast destination address or where the destination is an individual address, but the station sending the MSDU 
chooses to involve DSS. DSSs are provided between pairs of IEEE 802.1 1 MACs. 

3.23 extended rate set (ERS): The set of data transfer rates supported by a station (if any) beyond the 
extended service set (ESS) basic rate set. This set may include data transfer rates that will be defined in 
future physical layer (PHY) standards. 

3.24 extended service area (ESA): The conceptual area within which members of an extended service set 
(ESS) may communicate. An ESA is larger than or equal to a basic service area (BSA) and may involve sev- 
eral basic service sets (BSSs) in overlapping, disjointed, or both configurations. 

3.25 extended service set^ESS): A set of one or more interconnected basic service sets (BSSs) and inte- 
grated local area networks (LANs) that appears as a single BSS to the logical link control layer at any station 
associated with one of those BSSs. 

3.26 Gaussian frequency shift keying (GFSK): A modulation scheme in which the data is first filtered by a 
Gaussian filter in the baseband and then modulated with a simple frequency modulation. 

3.27 independent basic service set (IBSS): A BSS that forms a self-contained network, and in which no 
access to a distribution system (DS) is available. 
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3.28 infrastructure: The infrastructure includes the distribution system medium (DSM), access point (AP), 
and portal entities. It is also the logical location of distribution and integration service functions of an 
extended service set (ESS). An infrastructure contains one or more APs and zero or more portals in addition 
to the distribution system (DS). 

3.29 integration: The service that enables delivery of medium access control (MAC) service data units 
(MSDUs) between the distribution system (DS) and an existing, non-IEEE 802.1 1 local area network (via a 
portal). 

3.30 medium access control (MAC) management protocol data unit (MMPDU): The unit of data 
exchanged between two peer MAC entities to implement the MAC management protocol. 

3.31 medium access control (MAC) protocol data unit (MPDU): The unit of data exchanged between two 
peer MAC entities using the services of the physical layer (PHY). 

332 medium access control (MAC) service data unit (MSDU): Information that is delivered as a unit 
between MAC service access points (SAPs). 

3.33 minimally conformant network: An IEEE 802. 1 1 network in which two stations in a single basic ser- 
vice area (BSA) are conformant with ISO/IEC 8802- 1 1 : 1999. 

3.34 mobile station: A type of station that uses network communications while in motion. 

3.35 multicast: A medium access control (MAC) address that has the group bit set. A multicast MAC ser- 
vice data unit (MSDU) is one with a multicast destination address. A multicast MAC protocol data unit 
(MPDU) or control frame is one with a multicast receiver address. 

3.36 network allocation vector (NAV): An indicator, maintained by each station, of time periods when 
transmission onto the wireless medium (WM) will not be initiated by the station whether or not the station's 
clear channel assessment (CCA) function senses that the WM is busy. 

3.37 point coordination function (PCF): A class of possible coordination functions in which the coordina- 
tion function logic is active in only one station in a basic service set (BSS) at any given time that the network 
is in operation. 

3.38 portable station: A type of station that may be moved from location to location, but that only uses net- 
work communications while at a fixed location. 

3.39 portal: The logical point at which medium access control (MAC) service data units (MSDUs) from a 
non-IEEE 802.1 1 local area network (LAN) enter the distribution system (DS) of an extended service set 
(ESS). 

3.40 privacy: The service used to prevent the content of messages from being read by other than the 
intended recipients. 

3.41 reassociation: The service that enables an established association [between access point (AP) and sta- 
tion (STA)] to be transferred from one AP to another (or the same) AP. 

3.42 station (STA): Any device that contains an IEEE 802.1 1 conformant medium access control (MAC) 
and physical layer (PHY) interface to the wireless medium (WM). 

3.43 station basic rate: A data transfer rate belonging to the extended service set (ESS) basic rate set that is 
used by a station for specific transmissions. The station basic rate may change dynamically as frequently as 
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each medium access control (MAC) protocol data unit (MPDU) transmission attempt, based on local consid- 
erations at that station. 

3.44 station service (SS): The set of services that support transport of medium access control (MAC) ser- 
vice data units (MSDUs) between stations within a basic service set (BSS). 

3.45 time unit (TU): A measurement of time equal to 1024 us. 

3.46 unauthorized disclosure: The process of making information available to unauthorized individuals, 
entities, or processes. 

3.47 unauthorized resource use: Use of a resource not consistent with the defined security policy. 

3.48 unicast frame: A frame that is addressed to a single recipient, not a broadcast or multicast frame. Syn: 
directed address. 

3.49 wired equivalent privacy (WEP): The optional cryptographic confidentiality algorithm specified by 
IEEE 802. 1 1 used to provide data confidentiality that is subjectively equivalent to the confidentiality of a 
wired local area network (LAN) medium that does not employ cryptographic techniques to enhance privacy. 

3.50 wireless medium (WM): The medium used to implement the transfer of protocol data units (PDUs) 
between peer physical layer (PHY) entities of a wireless local area network (LAN). 



4. Abbreviations and acronyms 



ACK 

AID 

AP 

ATIM 

BSA 

BSS 



acknowledgment 
association identifier 
access point 

announcement traffic indication message 

basic service area 

basic service set 

basic service set identification 

clear channel assessment 

contention free 

contention-free period 

connection identifier 

contention period 

cyclic redundancy code 

carrier sense 

clear to send 

contention window 

destination address 

differential binary phase shift keying 

data communication equipment 

.distributed coordination function 

direct current level adjustment 

distributed (coordination function) interframe space 

data link layer 

desensitization 

differential quadrature phase shift keying 
distribution system 
destination service access point 
distribution system medium 



BSSID 



CCA 

CF 

CFP 

CID 

CP 

CRC 

CS 

CTS 

CW 

DA 



DBPSK 



DCE 

DCF 

DC LA 

DIFS 

DLL 

Dp 



DQPSK 



DS 

DSAP 
DSM 
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DSS 


distribution system service 


DSSS 


direct sequence spread spectrum 


DTIM 


delivery traffic indication message 


hD 


energy detection 


EIFS 


extended interframe space 


LIRP 


equivalent isotropically radiated power 


r— r> C 

ER5 


extended rate set 


ESA 


extended service area 


roc 


extended service set 


FC 


frame control 


FCS 


frame check sequence 


FER 


frame error ratio 


FH 


frequency hopping 


FHSS 


frequency-hopping spread spectrum 


FIFO 


first in first out 


GFSK 


Gaussian frequency shift keying 


IBSS 


independent basic service set 


ICV 


integrity check value 


IDU 


interface data unit 


IFS 


interframe space 


IMp 


intermodulation protection 


IR 


infrared 


ISM 


industrial, scientific, and medical 


IV 


initialization vector 


LAN 


local area network 


LLC 


logical link control 


LME 


layer management entity 


LRC 


long retry count 


lsb 


least significant bit 


MAC 


medium access control 


MDF 


management-defined field 


MIB 


management information base 


MLME 


MAC sublayer management entity 


MMPDU 


MAC management protocol data unit 


MPDU 


MAC protocol data unit 


msb 


most significant bit 


M5DU 


MAC service data unit 


XI/ A 

N/A 


not applicable 


NAV 


network allocation vector 


PC 


point coordinator 


PCF 


point coordination function 


nm r 

rlJU 


protocol data unit 


DLIV 

rni 


physical (layer) 


PHY-bAP 


physical layer service access point 


PIFS 


point (coordination function) interframe space 


PLCP 


• .physical layer convergence protocol 


PI MF 


physical layer management entity 


PMD 


physical medium dependent 


PMD-SAP 


physical medium dependent service access point 


PN 


pseudo- noise (code sequence) 


PPDU 


PLCP protocol data unit 


ppm 


parts per million 


PPM 


pulse position modulation 


PRNG 


pseudo- random number generator 
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PS 


power save (mode) 


PSDU 


PLCP SDU 


RA 


receiver address 


RF 


radio frequency 


RSSI 


received signal strength indication 


Ki b 


request to send 


D Y 

KA 


receive or receiver 


SA 


source address 


SAP 


service access point 


SDU 


service data unit 


SFD 


start frame delimiter 


SIFS 


short interframe space 


SLRC 


station long retry count 


SME 


station management entity 


SMT 


station management 


SQ 


signal quality (PN code correlation strength) 


SRC 


short retry count 


SS 


station service 


SSAP 


source service access point 


SSID 


service set identifier 


SSRC 


station short retry count 


STA 


station 


TA 


transmitter address 


TBTT 


target beacon transmission time 


TIM 


traffic indication map 


TSF 


timing synchronization function 


TU 


time unit 


TX 


transmit or transmitter 


TXE 


transmit enable 


UCT 


unconditional transition 


WAN 


wide area network 


WDM 


wireless distribution media 


WDS 


wireless distribution system 


WEP 


wired equivalent privacy 


WM 


wireless medium 
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5. General description 

5.1 General description of the architecture 

This subclause presents the concepts and terminology used within the ISO/IEC 8802-I I: 1999 document 
(referred to throughout the text as IEEE 802. 1 1 ). Specific terms are defined in Clause 3. Illustrations convey 
key IEEE 802. II concepts and the interrelationships of the architectural components. IEEE 802. 1 1 uses an 
architecture to describe functional components of an IEEE 802. 1 1 LAN. The architectural descriptions are 
not intended to represent any specific physical implementation of IEEE 802. II. 

5.1.1 How wireless LAN systems are different 

Wireless networks have fundamental characteristics that make them significantly different from traditional 
wired LANs. Some countries impose specific requirements for radio equipment in addition to those specified 
in this standard. 

5.1.1.1 Destination address does not equal destination location 

In wired LANs, an address is equivalent to a physical location. This is implicitly assumed in the design of 
wired LANs. In IEEE 802. 1 1, the addressable unit is a station (STA). The STA is a message destination, but 
not (in general) a fixed location. 

5.1 .1.2 The media impact the design 

The physical layers used in IEEE 802. 11 are fundamentally different from wired media. Thus IEEE 802 1 1 
PHYs 

a) Use a medium that has neither absolute nor readily observable boundaries outside of which stations 
with conformant PHY transceivers are known to be unable to receive network frames. 

b) Are unprotected from outside signals. 

c) Communicate over a medium significantly less reliable than wired PHYs. 

d) Have dynamic topologies. 

e) Lack full connectivity, and therefore the assumption normally made that every STA can hear every 
other STA is invalid (i.e., STAs may be "hidden" from each other). 

0 Have time-varying and asymmetric propagation properties. 

Because of limitations on wireless PHY ranges, wireless LANs intended to cover reasonable geographic dis- 
tances may be built from basic coverage building blocks. 

5.1.1 .3 The impact of handling mobile stations 

One of the requirements of IEEE 802.1 1 is to handle mobile as well as portable stations. A portable station 
is one that is moved from location to location, but that is only used while at a fixed location. Mobile stations 
actually access the LAN while in motion. 

For technical reasons, it is not sufficient to handle only portable stations. Propagation effects blur the distinc- 
tion between portable and mobile stations; stationary stations often appear to be mobile due to propagation 
effects. 

Another aspect of mobile stations is that they may often be battery powered. Hence power management is an 
important consideration. For example, it cannot be presumed that a station's receiver will always be powered on. 
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5.1.1.4 Interaction with other IEEE 802 layers 

IEEE 802. 1 1 is required to appear to higher layers [logical link control (LLC)] as a current style IEEE 802 
LAN. This requires that the IEEE 802.1 1 network handle station mobility within the MAC sublayer. To meet 
reliability assumptions (that LLC makes about lower layers), it is necessary for IEEE 802.1 1 to incorporate 
functionality that is untraditional for MAC sublayers. 

5.2 Components of the IEEE 802.11 architecture 

The IEEE 802. 1 1 architecture consists of several components that interact to provide a wireless LAN that 
supports station mobility transparently to upper layers. 

The basic service set (BSS) is the basic building block of an IEEE 802. 11 LAN. Figure 1 shows two BSSs, 
each of which has two stations that are members of the BSS. 

It is useful to think of the ovals used to depict a BSS as the coverage area within which the member stations 
of the BSS may remain in communication. (The concept of area, while not precise, is often good enough.) If 
a station moves out of its BSS, it can no longer directly communicate with other members of the BSS. 



5.2.1 The independent BSS as an ad hoc network 

The independent BSS (IBSS) is the most basic type of IEEE 802. 1 1 LAN. A minimum IEEE 802.1 1 LAN 
may consist of only two stations. 

Figure 1 shows two IBSSs/This mode of operation is possible when IEEE 802.1 1 stations are able to com- 
municate directly. Because this type of IEEE 802.1 1 LAN is often formed without pre-planning, for only as 
long as the LAN is needed, this type of operation is often referred to as an ad hoc network. 

5.2.1.1 STA to BSS association is dynamic 

The association between a STA and a BSS is dynamic (STAs turn on, turn off, come within range, and go out 
of range). To become a member of an infrastructure BSS, a station shall become "associated." These associ- 
ations are dynamic and involve the use of the distribution system service (DSS), which is described in 5.3.2, 



BSS 1 



802.11 Components 





BSS 2 



Figure 1 — Basic service sets 
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5.2.2 Distribution system c ncepts 

PHY limitations determine the direct station-to-station distance that may be supported. For some networks 
this distance is sufficient; for other networks, increased coverage is required. 

Instead of existing independently, a BSS may also form a component of an extended form of network that is 
built with multiple BSSs. The architectural component used to interconnect BSSs is the distribution system 
(DS). 

IEEE 802.1 1 logically separates the wireless medium (WM) from the distribution system medium (DSM). 
Each logical medium is used for different purposes, by a different component of the architecture. The IEEE 
802.1 1 definitions neither preclude, nor demand, that the multiple media be either the same or different. 

Recognizing that the multiple media are logically different is key to understanding the flexibility of the 
architecture. The IEEE 802.1 1 LAN architecture is specified independently of the physical characteristics of 
any specific implementation. 

The DS enables mobile device support by providing the logical services necessary to handle address to des- 
tination mapping and seamless integration of multiple BSSs. 

An access point (AP) is a STA that provides access to the DS by providing DS services in addition to acting 
as a STA. 

Figure 2 adds the DS and AP components to the IEEE 802. 1 1 architecture picture. 




Figure 2— Distribution systems and access points 



Data move between a BSS and the DS via an AP. Note that all APs are also STAs; thus they are addressable 
entities. The addresses used by an AP for communication on the WM and on the DSM are not necessarily the 
same. 

5.2.2.1 Extended service set (ESS): The large coverage network 

The DS and BSSs allow IEEE 802.1 1 to create a wireless network of arbitrary size and complexity. IEEE 
802, ! 1 refers to this type of network as the extended service set network. 
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The key concept is that the ESS network appears the same to an LLC layer as an IBSS network. Stations 
within an ESS may communicate and mobile stations may move from one BSS to another (within the same 
ESS) transparently to LLC. 

Nothing is assumed by IEEE 802. 11 about the relative physical locations of the BSSs in Figure 3. 




Figure 3 — Extended service set 



All of the following are possible: 

a) The BSSs may partially overlap. This is commonly used to arrange contiguous coverage within a 
physical volume. 

b) The BSSs could be physically disjointed. Logically there is no limit to the distance between BSSs. 

c) The BSSs may be physically collocated. This may be done to provide redundancy. 

d) One (or more) IBSS or ESS networks may be physically present in the same space as one (or more) 
ESS networks. This may arise for a number of reasons. Two of the most common are when an ad hoc 
network is operating in a location that also has an ESS network, and when physically overlapping 
IEEE 802.1 1 networks have been set up by different organizations. 

5.2.3 Area concepts 

For wireless PHYs, well-defined coverage areas simply do not exist. Propagation characteristics are dynamic 
and unpredictable. Small changes in position or direction may result in dramatic differences in signal 
strength. Similar effects occur whether a STA is stationary or mobile (as moving objects may impact station- 
to-station propagation). 

Figure 4 shows a signal strength map for a simple square room with a standard metal desk and an open door- 
way. Figure 4 is a static snapshot; the propagation patterns change dynamically as stations and objects in the 
environment move. In Figure 4 the dark (solid) blocks in the lower left are a metal desk and there is a door- 
way at the top right of the figure. The figure indicates relative differences in field strength with different 
intensities and indicates the variability of field strength even in a static environment. 

While the architecture diagrams show sharp boundaries for BSSs, this is an artifact of the pictorial represen- 
tation, not a physical reality. Since dynamic three-dimensional field strength pictures are difficult to draw, 
well-defined shapes are used by IEEE 802. 1 1 architectural diagrams to represent the coverage of a BSS. 
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Figure 4 — A representative signal intensity map 

Further description difficulties arise when attempting to describe collocated coverage areas. Consider Fig- 
ure 5, in which STA 6 could belong to BSS 2 or BSS 3. 



802.11 Components 




Figure 5— Collocated coverage areas 



While the concept of sets of stations is correct, it is often convenient to talk about areas. For many topics the 
concept of area is sufficient. Volume is a more precise term than area, though still not technically correct. For 
historical reasons and convenience, this standard uses the common term area. 
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5.2.4 Integration with wired LANs 

To integrate the IEEE 802. 1 1 architecture with a traditional wired LAN, a final logical architectural compo- 
nent is introduced — a portal. 

A portal is the logical point at which MSDUs from an integrated non-IEEE 802.1 1 LAN enter the IEEE 
802.1 1 DS. For example, a portal is shown in Figure 6 connecting to a wired IEEE 802 LAN. 



BSS 1 



802.XLAN 




802.11 Components 










Portal 

















STA3 




BSS 2 



Figure 6 — Connecting to other IEEE 802 LANs 



AH data from non-IEEE 802.1 1 LANs enter the IEEE 802.1 1 architecture via a portal. The portal provides 
logical integration between the IEEE 802.11 architecture and existing wired LANs. It is possible for one 
device to offer both the functions of an A P and a portal; this could be the case when a DS is implemented 
from IEEE 802 LAN components. 

In IEEE 802.1 1, the ESS architecture (APs and the DS) provides traffic segmentation and range extension. 
Logical connections between IEEE 802.1 1 and other LANs are via the portal. Portals connect between the 
DSM and the LAN medium that is to be integrated. 



5.3 Logical service interfaces 

The IEEE 802.1 1 architecture allows for the possibility that the DS may not be identical to an existing wired 
LAN. A DS may be create'd from many different technologies including current IEEE 802 wired LANs. 
IEEE 802. 1 1 does not constrain the DS to be either data link or network layer based. Nor does IEEE 802. 1 1 
constrain a DS to be either centralized or distributed in nature. 



IEEE 802.1 1 explicitly does not specify the details of DS implementations. Instead, IEEE 802.1 1 specifies 
services. The services are associated with different components of the architecture. There are two categories 
of IEEE 802.1 1 service — the station service (SS) and the distribution system service (DSS). Both categories 
of service are used by the IEEE 802. 1 1 MAC sublayer. 
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The complete set of IEEE 802. 1 1 architectural services are as follows: 



d ) 


r\ uineniiCoiiun 


b) 


Association 


c) 


Deauthentication 


d) 


Disassociation 


e) 


Distribution 


0 


Integration 


g) 


Privacy 


h) 


Reassociation 


•) 


MSDU delivery 



This set of services is divided into two groups: those that are part of every STA, and those that are part of a 
DS. 

5.3.1 Station service (SS) 

The service provided by stations is known as the station service. 

The SS is present in every IEEE 802.! 1 station (including APs, as APs include station functionality). The SS 
is specified for use by MAC sublayer entities. All conformant stations provide SS. 

The SS is as follows: 

a) Authentication 

b) Deauthentication 

c) Privacy 

d) MSDU delivery 

5.3.2 Distribution system service (DSS) 

The service provided by the DS is known as the distribution system service. 

These services are represented in the IEEE 802. 1 1 architecture by arrows within the APs, indicating that the 
services are used to cross media and address space logical boundaries. This is the convenient place to show the 
services in the picture. The physical embodiment of various services may or may not be within a physical AP. 

The DSSs are provided by the DS. They are accessed via a STA that also provides DSSs. A STA that is pro- 
viding access to DSS is an AP. 

The DSSs are as follows: 

a) Association 

b) Disassociation 

c) Distribution 

d) Integration 

e) Reassociation 

DSSs are specified for use by MAC sublayer entities. 
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Figure 7 combines the components from previous figures with both types of services to show the complete 
IEEE 802.11 architecture. 




Figure 7— Complete IEEE 802.11 architecture 



5.3.3 Multiple logical address spaces 

Just as the IEEE 802. 1 1 architecture allows for the possibility that the WM, DSM, and an integrated wired 
LAN may all be different physical media, it also allows for the possibility that each of these components 
may be operating within different address spaces. IEEE 802.1 1 only uses and specifies the use of the WM 
address space. 

Each IEEE 802.1 1 PHY operates in a single medium— the WM. The IEEE 802. 1 1 MAC operates in a single 
address space. MAC addresses are used on the WM in the IEEE 802. 1 1 architecture. Therefore, it is unnec- 
essary for the standard to explicitly specify that its addresses are "WM addresses." This is assumed through- 
out this standard. 

IEEE 802.11 has chosen to use the IEEE 802 48-bit address space (see 7.1.3.3.1). Thus IEEE 802.11 
addresses are compatible with the address space used by the IEEE 802 LAN family. 

The IEEE 802.1 1 choice of address space implies that for many instantiations of the IEEE 802. 1 1 architec- 
ture, the wired LAN MAC address space and the IEEE 802.1 1 MAC address space may be the same. In 
those situations where a DS that uses MAC level IEEE 802 addressing is appropriate, all three of the logical 
address spaces used within a system could be identical. While this is a common case, it is not the only com- 
bination allowed by the architecture. The IEEE 802.11 architecture allows for all three logical address 
spaces to be distinct. 

A multiple address space example is one in which the DS implementation uses network layer addressing. In 
this case, the WM address space and the DS address space would be different. 

The ability of the architecture to handle multiple logical media and address spaces is key to the ability of 
IEEE 802.1 1 to be independent of the DS implementation and to interface cleanly with network layer mobil- 
ity approaches. The implementation of the DS is unspecified and is beyond the scope of this standard. 
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5.4 Overview of th services 

There are nine services specified by IEEE 802. 1 1. Six of the services are used to support MSDU delivery 
between STAs. Three of the services are used to control IEEE 802. 1 1 LAN access and confidentiality. 

This subclause presents the services, an overview of how each service is used, and a description of how each 
service relates to other services and the IEEE 802.1 1 architecture. The services are presented in an order 
designed to help build an understanding of the operation of an IEEE 802.1 1 ESS network. As a result, the 
SSs and DSSs are intermixed in order (rather than being grouped by category). 

Each of the services is supported by one or more MAC frame types. Some of the services are supported by 
MAC management messages and some by MAC data messages. All of the messages gain access to the WM 
via the IEEE 802. 1 1 MAC sublayer medium access method specified in Clause 9. 

The IEEE 802.11 MAC sublayer uses three types of messages — data, management, and control (see 
Clause 7). The data messages are handled via the MAC data service path. 

MAC management messages are used to support the IEEE 802.1 1 services and are handled via the MAC 
management service data path. 

MAC control messages are used to support the delivery of IEEE 802. 1 1 data and management messages. 

The examples here assume an ESS network environment. The differences between the ESS and the IBSS 
network environments are discussed separately in 5.6. 

5.4.1 Distribution of messages within a DS 

5.4.1.1 Distribution 

This is the primary service used by IEEE 802. 1 1 STAs. It is conceptually invoked by every data message to 
or from an IEEE 802.1 1 STA operating in an ESS (when the frame is sent via the DS). Distribution is via a 
DSS. 

Refer to the ESS network in Figure 7 and consider a data message being sent from STA I to STA 4. The 
message is sent from STA 1 and received by STA 2 (the "input" AP). The AP gives the message to the distri- 
bution service of the DS. It is the job of the distribution service to deliver the message within the DS in such 
a way that it arrives at the appropriate DS destination for the intended recipient. In this example, the message 
is distributed to STA 3 (the "output" AP) and STA 3 accesses the WM to send the message to STA 4 (the 
intended destination). 

How the message is distributed within the DS is not specified by IEEE 802. 1 1. All IEEE 802. 1 1 is required 
to do is to provide the DS with enough information for the DS to be able to determine the "output" point that 
corresponds to the desired recipient. The necessary information is provided to the DS by the three associa- 
tion related services (association, reassociation, and disassociation). 

The previous example was a case in which the AP that invoked the distribution service was different from the 
AP that received the distributed message. If the message had been intended for a station that was a member 
of the same BSS as the sending station, then the "input" and "output" APs for the message would have been 
the same. 

In either example, the distribution service was logically invoked. Whether the message actually had to 
traverse the physical DSM or not is a DS implementation matter and is not specified by this standard. 
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While IEEE 802.1 1 does not specify DS implementations, it does recognize and support the use of the WM 
as the DSM. This is specifically supported by the IEEE 802. 1 1 frame formats. (Refer to Clause 7 for details.) 

5.4.1.2 Integration 

If the distribution service determines that the intended recipient of a message is a member of an integrated 
LAN, the "output" point of the DS would be a portal instead of an AP. 

Messages that are distributed to a portal cause the DS to invoke the Integration function (conceptually after 
the distribution service). The Integration function is responsible for accomplishing whatever is needed to 
deliver a message from the DSM to the integrated LAN media (including any required media or address 
space translations). Integration is a DSS. 

Messages received from an integrated LAN (via a portal) by the DS for an IEEE 802.1 1 STA will invoke the 
Integration function before the message is distributed by the distribution service. 

The details of an Integration function are dependent on a specific DS implementation and are outside the 
scope of this standard. 

5.4.2 Services that support the distribution service 

The primary purpose of a MAC sublayer is to transfer MSDUs between MAC sublayer entities. The infor- 
mation required for the distribution service to operate is provided by the association services. Before a data 
message can be handled by the distribution service, a STA shall be "associated." 

To understand the concept of association, it is necessary first to understand the concept of mobility. 

5.4.2.1 Mobility types 

The three transition types of significance to this standard that describe the mobility of stations within a 
network are as follows: 

a) No-transition: In this type, two subclasses that are usually indistinguishable are identified: 

1 ) Static — no motion. 

2) Local movement — movement within the PHY range of the communicating STAs [i.e., move- 
ment within a basic service area (BSA)]. 

b) BSS-transition: This type is defined as a station movement from one BSS in one ESS to another 
BSS within the same ESS. 

c) ESS-transition: This type is defined as station movement from a BSS in one ESS to a BSS in a dif- 
ferent ESS. This case is supported only in the sense that the STA may move. Maintenance of upper- 
layer connections cannot be guaranteed by IEEE 802. 1 1; in fact, disruption of service is likely to 
occur. 

The different association services support the different categories of mobility. 

5.4.2.2 Association 

To deliver a message within a DS, the distribution service needs to know which AP to access for the given 
IEEE 802.11 STA. This information is provided to the DS by the concept of association. Association is 
necessary, but not sufficient, to support BSS-transition mobility. Association is sufficient to support no- 
transition mobility. Association is a DSS. 

Before a STA is allowed to send a data message via an AP, it shall first become associated with the AP. The 
act of becoming associated invokes the association service, which provides the STA to AP mapping to the 
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DS. The DS uses this information to accomplish its message distribution service. How the information 
provided by the association service is stored and managed within the DS is not specified by this standard. 

At any given instant, a STA may be associated with no more than one AP. This ensures that the DS may 
determine a unique answer to the question, "Which AP is serving STA X?" Once an association is 
completed, a STA may make full use of a DS (via the AP) to communicate. Association is always initiated by 
the mobile STA, not the AP. 

An AP may be associated with many STAs at one time. 

A STA leams what APs are present and then requests to establish an association by invoking the association 
service. For details of how a station learns about what APs are present, see 1 1 . 1 .3. 

5.4.2.3 Reassociation 

Association is sufficient for no-transition message delivery between IEEE 802.1 1 stations. Additional func- 
tionality is needed to support BSS-transition mobility. The additional required functionality is provided by 
the reassociation service. Reassociation is a DSS. 

The reassociation service is invoked to "move" a current association from one AP to another. This keeps the 
DS informed of the current mapping between AP and STA as the station moves from BSS to BSS within an 
ESS. Reassociation also enables changing association attributes of an established association while the STA. 
remains associated with the same AP. Reassociation is always initiated by the mobile STA. 

5.4.2.4 Disassociation 

The disassociation service is invoked whenever an existing association is to be terminated. Disassociation is 
a DSS. 

In an ESS, this tells the DS to void existing association information. Attempts to send messages via the DS 
to a disassociated STA will be unsuccessful. 

The disassociation service may be invoked by either party to an association (non- AP STA or AP). Disassoci- 
ation is a notification, not a request. Disassociation cannot be refused by either party to the association. 

APs may need to disassociate STAs to enable the AP to be removed from a network for service or for other 
reasons. 

STAs shall attempt to disassociate whenever they leave a network. However, the MAC protocol does not 
depend on STAs invoking the disassociation service. (MAC management is designed to accommodate loss 
of an associated STA.) 

5.4.3 Access and confidentiality control services 

Two services are required for IEEE 802.1 1 to provide functionality equivalent to that which is inherent to 
wired LANs. The design of wired LANs assumes the physical attributes of wire. In particular, wired LAN 
design assumes the physically closed and controlled nature of wired media. The physically open medium 
nature of an IEEE 802.1 1 LAN violates those assumptions. 

Two services are provided to bring the IEEE 802. 1 1 functionality in line with wired LAN assumptions; 
authentication and privacy. Authentication is used instead of the wired media physical connection. Privacy is 
used to provide the confidential aspects of closed wired media. 
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5.4.3.1 Authentication 

In wired LANs, physical security can be used to prevent unauthorized access. This is impractical in wireless 
LANs since they have a medium without precise bounds. 

IEEE 802. 1 1 provides the ability to control LAN access via the authentication service. This service is used 
by all stations to establish their identity to stations with which they will communicate. This is true for both 
ESS and IBSS networks. If a mutually acceptable level of authentication has not been established between 
two stations, an association shall not be established. Authentication is an SS. 

IEEE 802,11 supports several authentication processes. The IEEE 802.11 authentication mechanism also 
allows expansion of the supported authentication schemes. IEEE 802, 1 1 does not mandate the use of any 
particular authentication scheme. 

IEEE 802.1 1 provides link-level authentication between IEEE 802. 11 STAs. IEEE 802.1 1 does not provide 
either end-to-end (message origin to message destination) or user-to-user authentication. IEEE 802. 1 1 
authentication is used simply to bring the wireless link up to the assumed physical standards of a wired link. 
(This use of authentication is independent of any authentication process that may be used in higher levels of 
a network protocol stack.) If authentication other than that described here is desired, it is recommended that 
IEEE Std 802.10-1992 [B3] 4 be implemented. 

If desired, an IEEE 802.11 network may be operated using Open System authentication (see 8.1.1). This 
may violate implicit assumptions made by higher network layers. In an Open System, any station may 
become authenticated. 

IEEE 802. 1 1 also supports Shared Key authentication. Use of this authentication mechanism requires imple- 
mentation of the wired equivalent privacy (WEP) option (see 8.2). In a Shared Key authentication system, 
identity is demonstrated by knowledge of a shared, secret, WEP encryption key. 

Management information base (MIB) functions are provided to support the standardized authentication 
schemes. 

IEEE 802.1 1 requires mutually acceptable, successful, authentication. 
A STA may be authenticated with many other STAs at any given instant. 
5.4.3.1.1 Preauthentication 

Because the authentication process could be time-consuming (depending on the authentication protocol in 
use), the authentication service can be invoked independently of the association service. 

Preauthentication is typically done by a STA while it is already associated with an AP (with which it previ- 
ously authenticated). IEEE "802.1 1 does not require that STAs preauthenticate with APs. However, authenti- 
cation is required before an association can be established. 

If the authentication is left until reassociation time, this may impact the speed with which a STA can reasso- 
ciate between APs, limiting BSS-transition mobility performance. The use of preauthentication takes the 
authentication service overhead out of the time-critical reassociation process. 

numbers in brackets correspond to those of the bibliography in Annex E. 
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5.4.3.2 Deauthentication 

The deauthentication service is invoked whenever an existing authentication is to be terminated. Deauthenti- 
cation is an SS. 

In an ESS, since authentication is a prerequisite for association, the act of deauthentication shall cause the 
station to be disassociated. The deauthentication service may be invoked by either authenticated party (non- 
AP STA or AP). Deauthentication is not a request; it is a notification. Deauthentication shall not be refused 
by either party. When an AP sends a deauthentication notice to an associated STA, the association shall also 
be terminated. 

5.4.3.3 Privacy 

In a wired LAN, only those stations physically connected to the wire may hear LAN traffic. With a wireless 
shared medium, this is not the case. Any IEEE 802. II -compliant STA may hear all like-PHY IEEE 802. 1 1 
traffic that is within range. Thus the connection of a single wireless link (without privacy) to an existing 
wired LAN may seriously degrade the security level of the wired LAN. 

To bring the functionality of the wireless LAN up to the level implicit in wired LAN design, IEEE 802.1 1 
provides the ability to encrypt the contents of messages. This functionality is provided by the privacy ser- 
vice. Privacy is an SS. 

IEEE 802.1 1 specifies an optional privacy algorithm, WEP, that is designed to satisfy the goal of wired LAN 
"equivalent" privacy. The algorithm is not designed for ultimate security but rather to be "at least as secure" 
as a wire." See Clause 8 for more details. 

IEEE 802.1 1 uses the WEP mechanism (see Clause 8) to perform the actual encryption of messages. MIB 
functions are provided to support WEP. 

Note that privacy may only be invoked for data frames and some Authentication Management frames. All 
stations initially start "in the clear" in order to set up the authentication and privacy services. 

The default privacy state for all IEEE 802.1 1 STAs is "in the clear." If the privacy service is not invoked, all 
messages shall be sent unencrypted. If this default is not acceptable to one party or the other, data frames 
shall not be successfully communicated between the LLC entities. Unencrypted data frames received at a 
station configured for mandatory privacy, as well as encrypted data frames using a key not available at the 
receiving station, are discarded without an indication to LLC (or without indication to distribution services 
in the case of "To DS" frames received at an AP). These frames are acknowledged on the WM [if received 
without frame check sequence (FCS) error] to avoid wasting WM bandwidth on retries. 

5.5 Relationships between services 

A STA keeps two state variables for each STA with which direct communication via the WM is needed: 

— Authentication state: The values are unauthenticated and authenticated. 

— Association state: The values are unassociated and associated. 

These two variables create three local states for each remote STA: 

— State I: Initial start state, unauthenticated, unassociated. 

— State 2: Authenticated, not associated. 

— State 3: Authenticated and associated. 



Copyright © 1999 IEEE. All rights reserved. 



2I 



ISO/IEC 8802-11; 1999(E) 

ANSI/IEEE Std 802.11, 1999 Edition LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



The relationships between these station state variables and the services are given in Figure 8. 




Figure 8 — Relationship between state variables and services 



The current state existing between the source and destination station determines the IEEE 802.11 frame 
types that may be exchanged between that pair of STAs (see Clause 7). The state of the sending STA given 
by Figure 8 is with respect to the intended receiving STA. The allowed frame types are grouped into classes 
and the classes correspond to the station state. In State I, only Class 1 frames are allowed. In State 2, either 
Class 1 or Class 2 frames are allowed. In State 3, all frames are allowed (Classes 1, 2, and 3). The frame 
classes are defined as follows: 

a) Class I frames (permitted from within States 1, 2, and 3): 

1 ) Control frames 

i) Request to send (RTS) 

ii) Clear to send (CTS) 

iii) Acknowledgment (ACK) 

iv) Contention-Free (CF)-End+ACK 

v) CF-End 

2) Management frames 

i) Probe request/response 

ii) Beacon 

iii) Authentication: Successful authentication enables a station to exchange Class 2 frames. 
Unsuccessful authentication leaves the STA in State 1 . 

iv) Deauthentication: Deauthentication notification when in State 2 or State 3 changes the 
STA's state to State I. The STA shall become authenticated again prior to sending Class 2 
frames. 

v) Announcement traffic indication message (ATIM) 

3) Data frames 

i) " Data: Data frames with frame control (FC) bits "To DS" and "From DS" both false. 

b) Class 2 frames (if and only if authenticated; allowed from within States 2 and 3 only): 
1) Management frames: 

i) Association request/response 

— Successful association enables Class 3 frames. 

— Unsuccessful association leaves STA in State 2. 

ii) Reassociation request/response 

— Successful reassociation enables Class 3 frames. 
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— Unsuccessful reassociation leaves the STA in State 2 (with respect to the STA that 
was sent the reassociation message). Reassociation frames shall only be sent if the 
sending STA is already associated in the same ESS. 

iii) Disassociation 

— Disassociation notification when in State 3 changes a Station's state to State 2. This 
station shall become associated again if it wishes to utilize the DS. 

If STA A receives a Class 2 frame with a unicast address in the Address l field from STA B that is 
not authenticated with STA A, STA A shall send a deauthentication frame to STA B. 

c) Class 3 frames (if and only if associated; allowed only from within State 3): 

1) Data frames 

— Data subtypes: Data frames allowed. That is, either the "To DS" or "From DS" FC bits 
may be set to true to utilize DSSs. 

2) Management frames 

— Deauthentication: Deauthentication notification when in State 3 implies disassociation as 
well, changing the STAs state from 3 to 1. The station shall become authenticated again 
prior to another association. 

3) Control frames 

— PS-Poll 

If STA A receives a Class 3 frame with a unicast address in the Address 1 field from STA B that is 
authenticated but not associated with STA A, STA A shall send a disassociation frame to STA B. 

If STA A receives a Class 3 frame with a unicast address in the Address 1 field from STA B that is 
not authenticated with STA A, STA A shall send a deauthentication frame to STA B. 

(The use of the word "receive" in this subclause refers to a frame that meets all of the filtering crite- 
ria specified in Clauses 8 and 9.) 

5.6 Differences between ESS and IBSS LANs 

In 5.2. 1 the concept of the IBSS LAN was introduced. It was noted that an IBSS is often used to support an 
ad hoc network. In an IBSS network, a STA communicates directly with one or more other STAs. 
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Consider the full IEEE 802. 1 1 architecture as shown in Figure 9. 




Figure 9— IEEE 802.11 architecture (again) 



An IBSS consists of STAs that are directly connected. Thus there is (by definition) only one BSS. Further, 
since there is no physical DS, there cannot be a portal, an integrated wired LAN, or the DSSs. The logical 
picture reduces to Figure 10. 



802.11 Independent BSS 




Figure 10 — Logical architecture of an IBSS 



Only the minimum two stations are shown in Figure 10. An IBSS may have an arbitrary number of members. 
In an IBSS, only Class 1 and Class 2 frames are allowed since there is no DS in an IBSS. 

The services that apply to an IBSS are the SSs. 

5.7 Message information contents that support the services 

Each service is supported by one or more IEEE 802. 1 1 messages. Information items are given by name; for 
corresponding values, see Clause 7. 
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5.7.1 Data 

For a STA to send data to another STA, it sends a data message, as shown below: 
Data messages 

— Message type: Data 

— Message subtype: Data 

— Information items: 

• IEEE source address of message 

• IEEE destination address of message 

• BSSID 

— Direction of message: From STA to STA 

5.7.2 Association 

For a STA to associate, the association service causes the following messages to occur: 
Association request 

— Message type: Management 

— Message subtype: Association request 

— Information items: 

• IEEE address of the STA initiating the association 

• IEEE address of the AP with which the initiating station will associate 

• ESS ID 

— Direction of message: From STA to AP 
Association response 

— Message type: Management 

— Message subtype: Association response 

— Information items: 

• Result of the requested association. This is an item with values "successful" and "unsuccessful 

• If the association is successful, the response shall include the association identifier (AID). 

— Direction of message: From AP to STA 

5.7.3 Reassociation 

For a STA to reassociate, the reassociation service causes the following message to occur: 
Reassociation request 

— Message type: Management 

— Message subtype: Reassociation request 

— Information items: 

• IEEE address of the STA initiating the reassociation 

• IEEE address of the AP with which the initiating station will reassociate 

• IEEE address of the AP with which the initiating station is currently associated 

• ESS ID 

— Direction of message: 

• From STA to AP (The AP with which the STA is requesting reassociation) 
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The address of the current AP is included for efficiency. The inclusion of the current AP address facilitates 
MAC reassociation to be independent of the DS implementation. 

Reassociation response 

— Message type: Management 

— Message subtype: Reassociation response 

— Information items: 

• Result of the requested reassociation. This is an item with values "successful" and "unsuccessful." 

• If the reassociation is successful, the response shall include the AID. 

— Direction of message: From AP to STA 

5.7.4 Disassociation 

For a STA to terminate an active association, the disassociation service causes the following message to 
occur: 

Disassociation 

— Message type: Management 

— Message subtype: Disassociation 

— Information items: 

• IEEE address of the station that is being disassociated. This shall be the broadcast address in the 
case of an AP disassociating with all associated stations. 

• IEEE address of the AP with which the station is currently associated. 

— Direction of message: From STA to STA (e.g., STA to AP or AP to STA) 

5.7.5 Privacy 

For a STA to invoke the WEP privacy algorithm (as controlled by the related MIB attributes, see Clause 1 1 X the 
privacy service causes MPDU encryption and sets the WEP frame header bit appropriately (see Clause 7). 

5.7.6 Authentication 

For a STA to authenticate with another STA, the authentication service causes one or more authentication 
management frames to be exchanged. The exact sequence of frames and their content is dependent on the 
authentication scheme invoked. For all authentication schemes, the authentication algorithm is identified 
within the management frame body. 

In an IBSS environment, either station may be the initiating STA (STA 1). In an ESS environment, STA 1 is 
the mobile STA, and STA 2 is the AP. 

Authentication (first frame of sequence) 

— Message type: Management 

— Message- subtype: Authentication 

— Information items: 

• Authentication algorithm identification 

• Station identity assertion 

• Authentication transaction sequence number 

• Authentication algorithm dependent information 

— Direction of message: First frame in the transaction sequence is always from STA I to STA 2. 

The first frame in an authentication sequence shall always be unencrypted. 
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Authentication (intermediate sequence frames) 

— Message type: Management 

— Message subtype: Authentication 

— Information items: 

• Authentication algorithm identification 

• Authentication transaction sequence number 

• Authentication algorithm dependent information 

— Direction of message: 

• Even transaction sequence numbers: From STA 2 to STA 1 

• Odd transaction sequence numbers: From STA 1 to STA 2 

Authentication (final frame of sequence) 

— Message type: Management 

— Message subtype: Authentication 

— Information items: 

• Authentication algorithm identification 

• Authentication transaction sequence number 

• Authentication algorithm dependent information 

• The result of the requested authentication. This is an item with values "successful" and "unsuc- 
cessful." 

— Direction of message: From STA 2 to STA 1 
5.7.7 Deauthentication 

For a STA to invalidate an active authentication, the following message is sent: 
Deauthentication 

— Message type: Management 

— Message subtype: Deauthentication 

— Information items: 

• IEEE address of the STA that is being deauthenticated 

• IEEE address of the STA with which the STA is currently authenticated 

• This shall be the broadcast address in the case of a STA deauthenticating all STAs currently 
authenticated. - 

— Direction of message: From STA to STA 
5.8 Reference model 

This standard presents the architectural view, emphasizing the separation of the system into two major parts: 
the MAC of the data link layer and the PHY. These layers are intended to correspond closely to the lowest 
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layers of the ISO/IEC basic reference model of Open Systems Interconnection (OSI) (ISO/IEC 7498- 1 
1994 5 ). The layers and sublayers described in this standard are shown in Figure II. 
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Figure 11— Portion of the ISO/IEC basic reference model covered in this standard 



'Information on normative references can be found in Clause 2. 
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6. MAC service definition 

6.1 Overview of MAC services 

6.1.1 Asynchronous data service 

This service provides peer LLC entities with the ability to exchange MAC service data units (MSDUs). To 
support this service, the local MAC uses the underlying PHY-level services to transport an MSDU to a peer 
MAC entity, where it will be delivered to the peer LLC. Such asynchronous MSDU transport is performed 
on a best-effort connectionless basis. There are no guarantees that the submitted MSDU will be delivered 
successfully. Broadcast and multicast transport is part of the asynchronous data service provided by the 
MAC. Due to the characteristics of the WM, broadcast and multicast MSDUs may experience a lower qual- 
ity of service, compared to that of unicast MSDUs. All STAs will support the asynchronous data service. 
Because operation of certain functions of the MAC may cause reordering of some MSDUs, as discussed in 
more detail below, there are two service classes within the asynchronous data service. By selecting the 
desired service class, each LLC entity initiating the transfer of MSDUs is able to control whether MAC enti- 
ties are or are not allowed to reorder those MSDUs. 

6.1 .2 Security services 

Security services in IEEE 802.1 1 are provided by the authentication service and the WEP mechanism. The 
scope of the security services provided is limited to station-to-station data exchange. The privacy service 
offered by an IEEE 802.1 1 WEP implementation is the encryption of the MSDU. For the purposes of this 
standard, WEP is viewed as a logical service located within the MAC sublayer as shown in the reference 
model, Figure 11. Actual implementations of the WEP service are transparent to the LLC and other layers 
above the MAC sublayer. 

The security services provided by the WEP in IEEE 802.1 1 are as follows: 

a) Confidentiality; 

b) Authentication; and 

c) Access control in conjunction with layer management. 

During the authentication exchange, parties A and B exchange authentication information as described in 
Clause 8. 

The MAC sublayer security services provided by WEP rely on information from non-layer 2 management or 
system entities. Management entities communicate information to WEP through a set of MIB attributes. 

6.1.3 MSDU ordering 

The services provided by the MAC sublayer permit, and may in certain cases require, the reordering of 
MSDUs. The MAC does not intentionally reorder MSDUs except as may be necessary to improve the likeli- 
hood of successful delivery -based on the current operational ("power management") mode of the designated 
recipient station(s). The sole effect of this reordering {if any), for the set of MSDUs received at the MAC ser- 
vice interface of any single station, is a change in the delivery order of broadcast and multicast MSDUs, rel- 
ative to directed MSDUs, originating from a single source station address. If a higher-layer protocol using 
the asynchronous data service cannot tolerate this possible reordering, the optional StrictlyOrdered service 
class should be used. MSDUs transferred between any pair of stations using the StrictlyOrdered service 
class are not subject to the relative reordering that is possible when the ReorderableMulticast service class is 
used. However, the desire to receive MSDUs sent using the StrictlyOrdered service class at a station pre- 
cludes simultaneous use of the MAC power management facilities at that station. 
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In order for the MAC to operate properly, the DS must meet the requirements oflSO/IEC 1 5802- 1 : 1995. 
Operational restrictions that ensure the appropriate ordering of MSDUs are specified in 9.8. 

6.2 Detailed service. specification 
6.2.1 MAC data services 

The IEEE 802. 1 1 MAC supports the following service primitives as defined in ISO/IEC 8802-2: 1998: 

— MA-UNITDATA .request 

— MA-UNITDATA.indication 

— MA - UNITD ATA - STATUS . indication 

The LLC definitions of the primitives and specify parameter value restrictions imposed by IEEE 802. II are 
given in 6.2.1.1 through 6.2.1.3. 

6.2.1.1 M A-U N ITDATA. req uest 

6.2.1.1.1 Function 

This primitive requests a transfer of an MSDU from a local LLC sublayer entity to a single peer LLC 
sublayer entity, or multiple peer LLC sublayer entities in the case of group addresses. 

6.2.1.1.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MA-UNITDATA. request ( 

source address, 

destination address, 

routing information, 

data, 

priority, 

service class 

) 

The source address (SA) parameter specifies an individual MAC sublayer address of the sublayer entity to 
which the MSDU is being transferred. 

The destination address (DA) parameter specifies either an individual or a group MAC sublayer entity 
address. 

The routing information parameter specifies the route desired for the data transfer (a null value indicates 
source routing is not to be used). For IEEE 802.1 1, the routing information parameter must be null. 

The data parameter specifies the MSDU to be transmitted by the MAC sublayer entity. For IEEE 802. 11 , the 
length of the MSDU must be less than or equal to 2304 octets. 

The priority parameter specifies the priority desired for the data unit transfer. IEEE 802.11 allows two 
values: Contention or Contention Free. 
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The service class parameter specifies the service class desired for the data unit transfer. IEEE 802. 1 1 allows 
two values: ReorderableMuiticast or StrictlyOrdered. 

6.2.1. 1.3 When generated 

This primitive is generated by the LLC sublayer entity whenever an MSDU is to be transferred to a peer 
LLC sublayer entity or entities. 

6.2.1.1.4 Effect of receipt 

The receipt of this primitive causes the MAC sublayer entity to append all MAC specified fields, including 
DA, SA, and all fields that are unique to IEEE 802.1 1, and pass the properly formatted frame to the lower 
layers for transfer to a peer MAC sublayer entity or entities. 

6.2.1 .2 MA-UNITDATA.indication 

6.2.1.2.1 Function 

This primitive defines the transfer of an MSDU from the MAC sublayer entity to the LLC sublayer entity, or 
entities in the case of group addresses. In the absence of error, the contents of the data parameter are logi- 
cally complete and unchanged relative to the data parameter in the associated MA-UNITDATA.request 
primitive. 

6.2.1 .2.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MA-UNITDATA.indication ( 

source address, 
destination address, 
routing information, 
data, 

reception status, 
priority, 
service class 
) 

The SA parameter is an individual address as specified by the SA field of the incoming frame. 

The DA parameter is either an individual or a group address as specified by the DA field of the incoming 
frame. 

The routing information parameter specifies the route that was used for the data transfer. IEEE 802. 1 1 will 
always set this field to null. 

The data parameter specifies the MSDU as received by the local MAC entity. 

The reception status parameter indicates the success or failure of the received frame for those frames that 
IEEE 802. 1 1 reports via an MA-UNITDATA.indication. This MAC only reports "success" when all failures 
of reception are discarded without generating MA-UNITDATA.indication. 

The priority parameter specifies the receive processing priority that was used for the data unit transfer. IEEE 
802.1 1 allows two values: Contention or Contention Free. 
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The service class parameter specifies the receive service class that was used for the data unit transfer. IEEE 
802. 1 1 allows two values: ReorderableMulticast or Strictly Ordered. 

6.2.1. 2.3 Wh n generated 

The MA-UNITDATA. indication primitive is passed from the MAC sublayer entity to the LLC sublayer 
entity or entities to indicate the arrival of a frame at the local MAC sublayer entity. Frames are reported only 
if they are validly formatted at the MAC sublayer, received without error, received with valid (or null) WEP 
encryption, and their destination address designates the local MAC sublayer entity. 

6.2.1.2.4 Effect of receipt 

The effect of receipt of this primitive by the LLC sublayer is dependent on the validity and content of the 
frame. 

6.2.1 .3 MA-UNITDATA-STATUS. indication 

6.2.1.3.1 Function 

This primitive has local significance and provides the LLC sublayer with status information for the corre- 
sponding preceding MA-UNITDATA. request primitive. 

6.2.1.3.2 Semantics of the service primitive 

The parameters of the primitive are as follows: 

MA-UNITDATA-STATUS. indication ( 

source address, 
destination address, 
transmission status, 
provided priority, 
provided service class 
) 

The SA parameter is an individual MAC sublayer entity address as specified in the associated MA-UNIT- 
DATA.request primitive. 

The DA parameter is either an individual or group MAC sublayer entity address as specified in the associ- 
ated MA-UNITDATA.request primitive. 

The transmission status parameter will be used to pass status information back to the local requesting LLC 
sublayer entity. IEEE 802.1 1 specifies the following values for transmission status: 

a) Successful; 

b) Undeliverable (for unacknowledged directed MSDUs when the aShortRetryMax or aLongRetryMax 
retry limit would otherwise be exceeded); 

c) Excessive data length; 

d) Non-null source routing; 

e) Unsupported priority (for priorities other than Contention or Contention Free); 

0 Unsupported service class (for service classes other than ReorderableMulticast or Strictly Ordered); 

g) Unavailable priority (for ContentionFree when no point coordinator is available, in which case the 
MSDU is transmitted with a provided priority of Contention); 
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h) Unavailable service class (for StrictlyOrdered service when the station's power management mode is 
other than "active"); 

i) Undeiiverable (TransmitMSDUTimer reached aMaxTransrnitMSDU Lifetime before successful 
delivery); 

j) Undeiiverable (no BSS available); 

k) Undeiiverable (cannot encrypt with a null key). 

The provided priority parameter specifies the priority that was used for the associated data unit transfer 
(Contention or ContentionFree). 

The provided service class parameter specifies the class of service used for the associated data unit transfer 
(Reorderable Multicast or StrictlyOrdered). 

6.2.1. 3.3 When generated 

The MA-UNITDATA-STATUS.indication primitive is passed from the MAC sublayer entity to the LLC sub- 
layer entity to indicate the status of the service provided for the corresponding MA-UNITDATA. request 
primitive. 

6.2.1 .3.4 Effect of receipt 

The effect of receipt of this primitive by the LLC sublayer is dependent upon the type of operation employed 
by the LLC sublayer entity. 
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7. Frame formats 

The format of the MAC frames is specified in this clause. All stations shall be able to properly construct 
frames for transmission and decode frames upon reception, as specified in this clause. 

7.1 MAC frame formats 

Each frame consists of the following basic components: 

a) A MAC header, which comprises frame control, duration, address, and sequence control informa- 
tion; 

b) A variable length frame body, which contains information specific to the frame type: 

c) A frame check sequence (FCS), which contains an IEEE 32-bit cyclic redundancy code (CRC). 

7.1.1 Conventions 

The MAC protocol data units (MPDUs) or frames in the MAC sublayer are described as a sequence of fields 
in specific order. Each figure in Clause 7 depicts the fields/sub fie Ids as they appear in the MAC frame and in 
the order in which they are passed to the physical layer convergence protocol (PLCP), from left to right. 

In figures, all bits within fields are numbered, from 0 to k, where the length of the field is k + 1 bit. The octet 
boundaries within a field can be obtained by taking the bit numbers of the field modulo 8. Octets within 
numeric fields that are longer than a single octet are depicted in increasing order of significance, from lowest 
numbered bit to highest numbered bit. The octets in fields longer than a single octet are sent to the PLCP in 
order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits. 

Any field containing a CRC is an exception to this convention and is transmitted commencing with the coef- 
ficient of the highest-order term. 

MAC addresses are assigned as ordered sequences of bits. The Individual/Group bit is always transferred 
first and is bit 0 of the first octet. 

Values specified in decimal are coded in natural binary unless otherwise stated. The values in Table 1 are in 
binary, with the bit assignments shown in the table. Values in other tables are shown in decimal notation. 

Reserved fields and sub fields are set to 0 upon transmission and are ignored upon reception. 

7.1 .2 General frame format 

The MAC frame format comprises a set of fields that occur in a fixed order in all frames. Figure 12 depicts 
the general MAC frame format. The fields Address 2, Address 3, Sequence Control, Address 4, and Frame 
Body are only present in certain frame types. Each field is defined in 7.1.3. The format of each of the indi- 
vidual frame types is defined in 7.2. 



Octets: 2 


2 


6 


6 


6 


2 


6 


0-2312 


4 




Frame 
Control 


Duration/ 
ID 


Address 1 


Address 2 


Address 3 


Sequence 
Control 


Address 4 


Frame 
Body 


FCS 
















► 







MAC Header 
Figure 12— MAC frame format 
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7.1.3 Frame fields 

7.1.3.1 Frame Control field 



The Frame Control field consists of the following subfields: Protocol Version, Type, Subtype, To DS, From 
DS, More Fragments, Retry, Power Management, More Data, Wired Equivalent Privacy (WEP), and Order. 
The format of the Frame Control field is illustrated in Figure 13. 
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4 




1 


1 
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Figure 13 — Frame Control field 



7.1.3.1.1 Protocol Version field 

The Protocol Version field is 2 bits in length and is invariant in size and placement across all revisions of this 
standard. For this standard, the value of the protocol version is 0. All other values are reserved. The revision 
level will be incremented only when a fundamental incompatibility exists between a new revision and the 
prior edition of the standard. A device that receives a frame with a higher revision level than it supports will : 
discard the frame without indication to the sending station or to LLC. 

7.1 .3.1 .2 Type and Subtype fields 

The Type field is 2 bits in length, and the Subtype field is 4 bits in length. The Type and Subtype fields 
together identify the function of the frame. There are three frame types: control, data, and management. 
Each of the frame types have several defined subtypes. Table 1 defines the valid combinations of type and 
subtype. 

7.1. 3.1. 3 To DS field 

The To DS field is l bit in length and is set to I in data type frames destined for the DS. This includes all data 
type frames sent by STAs associated with an AP. The To DS field is set to 0 in all other frames. 

7.1.3.1.4 From DS field 

.The From DS field is 1 bit in length and is set to I in data type frames exiting the DS. It is set to 0 in all other 
frames. 

The permitted To/From DJrbit combinations and their meanings are given in Table 2. 

7.1.3.1.5 More Fragments field 

The More Fragments field is 1 bit in length and is set to 1 in all data or management type frames that have 
another fragment of the current MSDU or current MMPDU to follow. It is set to 0 in all other frames. 
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Table 1— Valid type and subtype combinations 



Type value 
b3 b2 


Type 
description 


Subtype value 
b7 b6 b5 b4 


Subtype description 


00 


Management 


0000 


Association request 


00 


Management 


0001 


Association response 


00 


Management 


0010 


Reassociation request 


00 


Management 


0011 


Reassociation response 


00 


Management 


0100 


Probe request 


00 


Management 


0101 


Probe response 


00 


Management 


0110-0111 


Reserved 


00 


Management 


1000 


Beacon 


00 


Management 


1001 


Announcement traffic indication message (ATIM) 


00 


Management 


1010 


Disassociation 


00 


Management 


1011 


Authentication 


00 


Management 


1100 


Deauthentication 


00 


Management 


1 1 0 1— 1 1 1 1 


Reserved 


01 


Control 


0000-1001 


Reserved 


01 


Control 


1010 


Power Save (PS)-Poll 


01 


Control 


1011 


Request To Send(RTS) 


01 


Control 


uoo 


Clear To Send(CTS) 


01 


Control 


1101 


Acknowledgment (ACK) 


01 


Control 


11 10 


Contention-Free (CF)-End 


01 


Control 


lilt 


CF-End + CF-Ack 


10 


Data 


0000 


Data 


10 


Data 


0001 


Data + CF-Ack 


10 


Data 


0010 


Data + CF- Poll 


10 


Data 


001 1 


Data + CF-Ack + CF-Poll 


10 


Data 


0100 


Null function (no data) 


10 


Data 


0101 


CF-Ack (no data) 


10 


Data 


0110 


CF-Poll (no data) 


10 


Data 


0111 


CF-Ack + CF-Poll (no data) 


10 


Data 


1000-11 11 


Reserved 


11 


Reserved 


0000-11 11 


Reserved 
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Table 2— To/From DS combinations in data type frames 



To/From DS values 


Meaning 


To DS = 0 
From DS = 0 


A data frame direct from one STA to another STA within the same 
IBSS, as well as all management and control type frames. 


To DS = 1 
From DS = 0 


Data frame destined for the DS. 


To DS = 0 
From DS = 1 


Data frame exiting the DS. 


To DS = 1 
From DS = 1 


Wireless distribution system (WDS) frame being distributed from 
one AP to another AR 



7.1.3.1.6 Retry field 

The Retry field is 1 bit in length and is set to 1 in any data or management type frame that is a retransmission 
of an earlier frame. It is set to 0 in all other frames. A receiving station uses this indication to aid in the 
process of eliminating duplicate frames. 

7.1.3.1.7 Power Management field 

The Power Management field is 1 bit in length and is used to indicate the power management mode of a 
STA. The value of this field remains constant in each frame from a particular STA within a frame exchange 
sequence defined in 9.7. The value indicates the mode in which the station will be after the successful com- 
pletion of the frame exchange sequence. 

A value of 1 indicates that the STA will be in power-save mode. A value of 0 indicates that the STA will be 
in active mode. This field is always set to 0 in frames transmitted by an AP. 

7.1.3.1.8 More Data field 

The More Data field is I bit in length and is used to indicate to a STA in power-save mode that more 
MSDUs, or MMPDUs are buffered for that STA at the AP. The More Data field is valid in directed data or 
management type frames transmitted by an AP to an STA in power-save mode. A value of 1 indicates that at 
least one additional buffered MSDU, or MMPDU, is present for the same STA. 

The More Data field may be set to 1 in directed data type frames transmitted by a contention- free (CF)- 
Pollable STA to the point coordinator (PC) in response to a CF-Poll to indicate that the STA has at least one 
additional buffered MSDU available for transmission in response to a subsequent CF-Poll. 

The More Data field is set to 0 in all other directed frames. 

The More Data field is set to 1 in broadcast/multicast frames transmitted by the AP, when additional broad- 
cast/multicast MSDUs, or MMPDUs, remain to be transmitted by the AP during this beacon interval. The 
More Data field is set to 0 in broadcast/multicast frames transmitted by the AP when no more broadcast/ 
multicast MSDUs, or MMPDUs, remain to be transmitted by the AP during this beacon interval and in all 
broadcast/multicast frames transmitted by non-AP stations. 

7.1.3.1.9 WEP field 

The WEP field is 1 bit in length. It is set to 1 if the Frame Body field contains information that has been 
processed by the WEP algorithm. The WEP field is only set to 1 within frames of type Data and frames of 
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type Management, subtype Authentication. The WEP field is set to 0 in all other frames. When the WEP bit 
is set to 1, the Frame Body field is expanded as defined in 8.2.5. 

7.1.3.1.10 Order field 

The Order field is 1 bit in length and is set to 1 in any data type frame that contains an MSDU, or fragment 
thereof, which is being transferred using the Strictly Ordered service class. This field is set to 0 in all other 
frames. 

7.1.3.2 Duration/ID field 

The Duration/ID field is 16 bits in length. The contents of this field are as follows: 

a) In control type frames of subtype Power Save (PS)-Poll, the Duration/ID field carries the association 
identity (AID) of the station that transmitted the' frame in the 14 least significant bits (lsb), with the 
2 most significant bits (msb) both set to 1. The value of the AID is in the range 1-2007. 

b) In all other frames, the Duration/ID field contains a duration value as defined for each frame type in 
7.2. For frames transmitted during the contention- free period (CFP), the duration field is set to 
32 768. 

Whenever the contents of the Duration/ID field are less than 32 768, the duration value is used to update the 
network allocation vector (NAV) according to the procedures defined in Clause 9. 

The encoding of the Duration/ID field is given in Table 3. 



Table 3 — Duration/ID field encoding 



Bit 15 


Bit 14 


Bits 13-0 


Usage 


0 


0-32 767 


Duration 


1 


0 


0 


Fixed value within frames transmitted during the CFP 


I 


0 


1-16383 


Reserved 


I 


t 


0 


Reserved 


1 


1 


1-2 007 


AID in PS-Poll frames 


1 


I 


2 008-16 383 


Reserved 



7.1.3.3 Address fields 

There are four address fields in the MAC frame format. These fields are used to indicate the BSSID, source 
address, destination address, transmitting station address, and receiving station address. The usage of the 
four address fields in each frame type is indicated by the abbreviations BSSID, DA, SA, RA, and TA, indi- 
cating basic service set identifier (BSSID), Destination Address, Source Address, Receiver Address, and 
Transmitter Address, respectively. Certain frames may not contain some of the address fields. 

Certain address field usage is specified by the relative position of the address field (1-4) within the MAC 
header, independent of the type of address present in that field. For example, receiver address matching is 
always performed on the contents of the Address 1 field in received frames, and the receiver address of CTS 
and ACK frames is always obtained from the Address 2 field in the corresponding RTS frame, or from the 
frame being acknowledged. 
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7.1.3.3.1 Address repres ntation 

Each Address field contains a 48-bit address as defined in 5.2 of IEEE Std 802-1990. 

7.1.3.3.2 Address designation 

A MAC sublayer address is one of the following two types: 

a) Individual address. The address associated with a particular station on the network. 

b) Group address. A multidestination address, associated with one or more stations on a given network. 
The two kinds of group addresses are as follows: 

1) Multicast-group address. An address associated by higher-level convention with a group of 
logically related stations. 

2) Broadcast address. A distinguished, predefined multicast address that always denotes the set of 
all stations on a given LAN. All Is in the Destination Address field are interpreted to be the 
broadcast address. This group is predefined for each communication medium to consist of all 
stations actively connected to that medium; it is used to broadcast to all the active stations on 
that medium. All stations are able to recognize the broadcast address. It is not necessary that a 
station be capable of generating the broadcast address. 

The address space is also partitioned into locally administered and universal (globally administered) 
addresses. The nature of a body and the procedures by which it administers these universal (globally admin- 
istered) addresses is beyond the scope of this standard. See IEEE Std 802-1990 for more information. 

7.1.3.3.3 BSSID field 

The BSSID field is a 48-bit field of the same format as an IEEE 802 MAC address. This field uniquely iden- 
tifies each BSS. The value of this field, in an infrastructure BSS, is the MAC address currently in use by the * 
STAin the AP of the BSS. 

The value of this field in an IBSS is a locally administered IEEE MAC address formed from a 46-bit random 
number generated according to the procedure defined in 1 1 . 1 .3. The individual/group bit of the address is set 
to 0. The universal/local bit of the address is set to I . This mechanism is used to provide a high probability of 
selecting a unique BSSID. 

The value of all Is is used to indicate the broadcast BSSID. A broadcast BSSID may only be used in the 
BSSID field of management frames of subtype probe request. 

7.1 .3.3.4 Destination Address (DA) field 

The DA field contains an IEEE MAC individual or group address that identifies the MAC entity or entities 
intended as the final recipient(s) of the MSDU (or fragment thereof) contained in the frame body field. 

7.1 .3.3.5 Source Address (SA) field 

The SA field contains an IEEE MAC individual address that identifies the MAC entity from which the trans- 
fer of the MSDU (or fragment thereof) contained in the frame body field was initiated. The individual/group 
bit is always transmitted as a zero in the source address. 

7.1 .3.3.6 Receiver Address (RA) field 

The RA field contains an IEEE MAC individual or group address that identifies the intended immediate 
recipient STA(s), on the WM, for the information contained in the frame body field. 
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7.1 .3.3.7 Transmitter Address (TA) field 

The TA field contains an IEEE MAC individual address that identifies the STA that has transmitted, onto the 
WM, the MPDU contained in the frame body field. The Individual/Group bit is always transmitted as a zero 
in the transmitter address. 

7.1.3.4 Sequence Control field 

The Sequence Control field is 1 6 bits in length and consists of two subfields, the Sequence Number and the 
Fragment Number. The format of the Sequence Control field is illustrated in Figure 14. 



BO 



B3 B4 



B15 



Fragment Number 



Sequence Number 



Bits: 4 12 

Figure 14 — Sequence Control field 



7.1.3.4.1 Sequence Number field 

The Sequence Number field is a 12-bit field indicating the sequence number of an MSDU or MMPDU. Each 
MSDU or MMPDU transmitted by a STA is assigned a sequence number. Sequence numbers are assigned 
from a single modulo 4096 counter, starting at 0 and incrementing by I for each MSDU or MMPDU. Each 
fragment of an MSDU or MMPDU contains the assigned sequence number. The sequence number remains 
constant in all retransmissions of an MSDU, MMPDU, or fragment thereof. 

7.1.3.4.2 Fragment Number field 

The Fragment Number field is a 4-bit field indicating the number of each fragment of an MSDU or 
MMPDU. The fragment number is set to zero in the first or only fragment of an MSDU or MMPDU and is 
incremented by one for each successive fragment of that MSDU or MMPDU. The fragment number remains 
constant in all retransmissions of the fragment. 

7.1.3.5 Frame Body field 

The Frame Body is a variable length field that contains information specific to individual frame types and 
subtypes. The minimum frame body is 0 octets. The maximum length frame body is defined by the maxi- 
mum length (MSDU + ICV + IV), where ICV and IV are the WEP fields defined in 8.2.5. 

7.1.3.6 FCS field 

The FCS field is a 32-bit field containing a 32-bit CRC. The FCS is calculated over all the fields of the MAC 
header and the Frame Body field. These are referred to as the calculation fields. 

The FCS is calculated using the following standard generator polynomial of degree 32: 

CW=^ 32 + x 26 +x 23 +x 22 +x 16 + ^Ux 1 Ux 10 +x 8 +jc 7 + x 5 + x 4 + x 2 +.v+1 

The FCS is the I 's complement of the sum (modulo 2) of the following: 

a) The remainder of jc* x (jc 31 + * 30 + jc 29 + . . .+ jc 2 + x + 1 ) divided (modulo 2) by G(x\ where k is the 
number of bits in the calculation fields, and 
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b) The remainder after multiplication of the contents (treated as a polynomial) of the calculation fields 
by .r 32 and then division by G(x). 

The FCS field is transmitted commencing with the coefficient of the highest-order term. 

As a typical implementation, at the transmitter, the initial remainder of the division is preset to all I 's and is 
then modified by division of the calculation fields by the generator polynomial G(x). The I *s complement of 
this remainder is transmitted, with the highest-order bit first, as the FCS field. 

At the receiver, the initial remainder is preset to all l 's and the serial incoming bits of the calculation fields 
and FCS, when divided by G(x)> results in the absence of transmission errors, in a unique nonzero remainder 
value. The unique remainder value is the polynomial: 

^l + ^0 + ^6 + ^5 + ^4 +x 18 + x 15 +x 14 +t 12 + ^ll +x 10 +x 8 +x 6 + x 5 +x 4 + ^ +x+1 

7.2 Format of individual frame types 
7.2.1 Control frames 

In the following descriptions, "immediately previous" frame means a frame whose reception concluded 
within the prior short interframe space (SIFS) interval. 

The subfields within the Frame Control field of control frames are set as illustrated in Figure 1 5. 
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Figure 15 — Frame Control field subfield values within control frames 
7.2.1.1 Request To Send (RTS) frame format 

The frame format for the RTS frame is as defined in Figure 16. 



Octets: 2 


2 
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4 




Frame 
Control 


Duration 


RA 


TA 


FCS 



MAC Header 
Figure 16 — RTS frame 

The RA of the RTS frame is the address of the STA, on the WM, that is the intended immediate recipient of 
the pending directed data or management frame. 



The TA is the address of the STA transmitting the RTS frame. 
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The duration value is the time, in microseconds, required to transmit the pending data or management frame, 
plus one CTS frame, plus one ACK frame, plus three SIFS intervals. If the calculated duration includes a 
fractional microsecond, that value is rounded up to the next higher integer. 

7.2.1 .2 Clear To Send (CTS) frame format 

The frame format for the CTS frame is as defined in Figure 17. 

Octets: 2 2 6 4 



Frame 
Control 


Duration 


RA 


FCS 



► 

MAC Header 

Figure 17 — CTS frame 



The RA of the CTS frame is copied from the TA field of the immediately previous RTS frame to which the 
CTS is a response. 

The duration value is the value obtained from the Duration field of the immediately previous RTS frame, 
minus the time, in microseconds, required to transmit the CTS frame and its SIFS interval. If the calculated 
duration includes a fractional microsecond, that value is rounded up to the next higher integer. 

7.2.1.3 Acknowledgment (ACK) frame format 

The frame format for the ACK frame is as defined in Figure 1 8. 

Octets: 2 2 6 4 



Frame 
Control 


Duration 


RA 


FCS 



MAC Header 
Figure 1 8— ACK frame 



The RA of the ACK frame is copied from the Address 2 field of the immediately previous directed data, 
management, or PS-Poll control frame. 

If the More Fragment bit was set to 0 in the Frame Control field of the immediately previous directed data or 
management frame, the duration value is set to 0. If the More Fragment bit was set to 1 in the Frame Control 
field of the immediately previous directed data or management frame, the duration value is the value 
obtained from the Duration field of the immediately previous data or management frame, minus the time, in 
microseconds, required to transmit the ACK frame and its SIFS interval If the calculated duration includes a 
fractional microsecond, that, value is rounded up to the next higher integer. 

7.2.1.4 Power-Save Poll (PS-Poll) frame format 

The frame format for the PS-Poll frame is as defined in Figure 19. 

The BSSID is the address of the STA contained in the AP. The TA is the address of the STA transmitting the 
frame. The AID is the value assigned to the STA transmitting the frame by the AP in the association response 
frame that established that STA's current association. 
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Octets: 2 2 6 6 4 



Frame 
Control 


AID 


BSSID 


TA 


FCS 



► 

MAC Header 

Figure 19— PS-Poll frame 



The AID value always has its two most significant bits each set to I. All STAs, upon receipt of a PS-Poll 
frame, update their NAV settings as appropriate under the coordination function rules using a duration value 
equal to the time, in microseconds, required to transmit one ACK frame plus one SIFS interval. 

7.2.1.5 CF-End frame format 

The frame format for the CF-End frame is as defined in Figure 20. 

Octets: 2 2 6 6 4 



Frame 
Control 


Duration 


RA 


BSSID 


FCS 



« ► 

MAC Header 
Figure 20— CF-End frame 



The BSSID is the address of the STA contained in the AR The RA is the broadcast group address. 

The Duration field is set to 0. 

7.2.1.6 CF-End + CF-Ack frame format 

The frame format for the contention-free-end acknowledge (CF-End + CF-Ack) frame is as defined in Fig- 
ure 2 1 . 

Octets: 2 2 6 6 4 



Frame 
Control 


Duration 


RA 


BSSID 


FCS 



MAC Header 
Figure 21— CF-End + CF-Ack Frame 



The BSSID is the address of the STA contained in the AP The RA is the broadcast group address. 
The Duration field is set to 0. 
7.2.2 Data frames 

The frame format for a Data frame is independent of subtype and is as defined in Figure 22. 
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Oaets: 2 2 6 6 6 2 6 0 - 2312 4 
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MAC Header 



Figure 22— Data frame 

The content of the Address fields of the data frame is dependent upon the values of the To DS and From DS 
bits and is defined in Table 4. Where the content of a field is shown as not applicable (N/A), the field is omit- 
ted. Note that Address 1 always holds the receiver address of the intended receiver (or, in the case of multi- 
cast frames, receivers), and that Address 2 always holds the address of the station that is transmitting the 
frame. 



Table 4 —Address field contents 



ToDS 


From DS 


Address 1 


Address 2 


Address 3 


Address 4 


0 


0 


DA 


SA 


BSSID 


N/A 


0 


1 


DA 


BSSID 


SA 


N/A 


1 


0 


BSSID 


SA 


DA 


N/A 


I 


1 


RA 


TA 


DA 


SA 



A station uses the contents of the Address I field to perform address matching for receive decisions. In cases 
where the Address 1 field contains a group address, the BSSID also is validated to ensure that the broadcast 
or multicast originated in the same BSS. 

A station uses the contents of the Address 2 field to direct the acknowledgment if an acknowledgment is 
necessary. 

The DA is the destination of the MSDU (or fragment thereof) in the frame body field. 

The SA is the address of the MAC entity that initiated the MSDU (or fragment thereof) in the frame body 
field. 

The RA is the address of the STA contained in the AP in the wireless distribution system that is the next 
immediate intended recipient of the frame. 

The TA is the address of the. STA contained in the A P in the wireless distribution system that is transmitting 
the frame. 

The BSSID of the Data frame is determined as follows: 

a) If the station is an AP or is associated with an AP, the BSSID is the address currently in use by the 
STA contained in the A P. 

b) If the station is a member of an IBSS, the BSSID is the BSSID of the IBSS. 
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The frame body consists of the MSDU or a fragment thereof, and a WEP IV and ICV (if and only if the WEP 
subfield in the frame control field is set to I). The frame body is null (0 octets in length) in data frames of 
Subtype Null function (no data), CF-Ack (no data), CF-Poll (no data), and CF-Ack+CF-Poll (no data). 



Within all data type frames sent during the CFP, the Duration field is set to the value 32 768. Within all data 
type frames sent during the contention period, the Duration field is set according to the following rules: 

— If the Address 1 field contains a group address, the duration value is set to 0. 

— If the More Fragments bit is set to 0 in the Frame Control field of a frame and the Address I field 
contains an individual address, the duration value is set to the time, in microseconds, required to 
transmit one ACK frame, plus one SIFS interval. 

— If the More Fragments bit is set to I in the Frame Control field of a frame, and the Address 1 field 
contains an individual address, the duration value is set to the time, in microseconds, required to 
transmit the next fragment of this data frame, plus two ACK frames, plus three SIFS intervals. 



The duration value calculation for the data frame is based on the rules in 9.6 that determine the data rate at 
which the control frames in the frame exchange sequence are transmitted. If the calculated duration includes 
a fractional microsecond, that value is rounded up to the next higher integer. All stations process Duration 
field values less than or equal to 32 767 from valid data frames to update their NAV settings as appropriate 
under the coordination function rules. 

7.2.3 Management frames 

The frame format for a Management frame is independent of frame subtype and is as defined in Figure 23. 



Octets: 2 


2 


6 


6 


6 


2 


0-2312 


4 




Frame 
Control 


Duration 


DA 


SA 


BSSID 


Sequence 
Control 


Frame Body 


FCS 



MAC Header 

Figure 23 — Management frame format 



A STA uses the contents of the Address I field to perform the address matching for receive decisions. In the 
case where the Address 1 field contains a group address and the frame type is other than Beacon, the BSSID 
also is validated to ensure that the broadcast or multicast originated in the same BSS. If the frame type is 
Beacon, other address matching rules apply, as specified in 1 1.1 .2.3. 

The address fields for management frames do not vary by frame subtype. 

• The BSSID of the management frame is determined as follows: 

a) If the station is an AP or is associated with an AP, the BSSID is the address currently in use by the 
STA contained in the AP. 

b) If the station is a member of an IBSS, the BSSID is the BSSID of the IBSS. 

c) In Management frames of subtype Probe Request, the BSSID is either a specific BSSID, or the 
broadcast BSSID as defined in the procedures specified in Clause 10. 

The DA is the destination of the frame. 

The SA is the address of the station transmitting the frame. 
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Within all management type frames sent during the CFP, the Duration field is set to the value 32 768. Within 
all management type frames sent during the contention period, the Duration field is set according to the 
following rules: 

— If the DA field contains a group address, the duration value is set to 0. 

— If the More Fragments bit is set to 0 in the Frame Control field of a frame and the DA contains an 
individual address, the duration value is set to the time, in microseconds, required to transmit one 
ACK frame, plus one SIFS interval. 

— If the More Fragments bit is set to 1 in the Frame Control field of a frame, and the DA contains an 
individual address, the duration value is the time, in microseconds, required to transmit the next 
fragment of this management frame, plus two ACK frames, plus three SIFS intervals. 

The duration value calculation for the management frame is based on the rules in 9.6 that determine the data 
rate at which the control frames in the frame exchange sequence are transmitted. If the calculated duration 
includes a fractional microsecond, that value is rounded up to the next higher integer. All stations process 
Duration field values less than or equal to 32 767 from valid management frames to update their NAV 
settings as appropriate under the coordination function rules. 

The frame body consists of the fixed fields and information elements defined for each management frame 
subtype. All fixed fields and information elements are mandatory unless stated otherwise, and they can 
appear only in the specified order. Stations encountering an element type they do not understand ignore that 
element. Element type codes not explicitly defined in this standard are reserved, and do not appear in any 
frames. 

7.2.3.1 Beacon frame format 

The frame body of a management frame of subtype Beacon contains the information shown in Table 5. 



Table 5 — Beacon frame body 



Order 


Information 


Notes 


I 


Time stamp 




2 


Beacon interval 




3 


Capability information 




4 


SSID 




5 


Supported rates 




6 


FH Parameter Set 


The FH Parameter Set information element is present within Beacon 
frames generated by STAs using frequency-hopping PHYs. 


7 


DS Parameter Set 


The DS Parameter Set information element is present within Beacon 
frames generated by STAs using direct sequence PHYs. 


8 


CF Parameter Set 


The CF Parameter Set information element is only present within 
Beacon frames generated by APs supporting a PCR 


9 


IBSS Parameter Set 


The IBSS Parameter Set information element is only present within 
Beacon frames generated by STAs in an IBSS. 


10 


TIM 


The TIM information element is only present within Beacon frames 
generated by APs. 



7.2.3.2 IBSS Announcement Traffic Indication Message (ATIM) frame format 

The frame body of a management frame of subtype ATIM is null. 
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7.2.3.3 Disassociation frame format 

The frame body of a management frame of subtype Disassociation contains the information shown in Table 6. 



Table 6 — Disassociation frame body 



Order 


Information 


1 


Reason code 



7.2.3.4 Association Request frame format 

The frame body of a management frame of subtype Association Request contains the information shown in 
Table 7. 

Table 7 — Association Request frame body 



Order 


Information 


1 


Capability information 


2 


Listen interval 


3 


SSID 


4 


Supported rates 



7.2.3.5 Association Response frame format 

The frame body of a management frame of subtype Association Response contains the information shown in 
Table 8. 



Table 8 — Association Response frame body 



Order 


Information 


1 


Capability information 


2 


Status code 


3 


Association ID (AID) 


4 


Supported rates 



7.2.3.6 Reassociation Request frame format 

The frame body of a management frame of subtype Reassociation Request contains the information shown 
in Table 9. 
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Table 9 — Reassociation R quest frame body 



Order 


Information 


i 


Capability information 


2 


Listen interval 


3 


Current AP address 


4 


SSID 


5 


Supported rates 



7.2.3.7 Reassociation Response frame format 

The frame body of a management frame of subtype Reassociation Response contains the information shown 
in Table 10. 



Table 10 — Reassociation Response frame body 



Order 


Information 


I 


Capability information 


2 


Status code 


3 


Association ID (AID) 


4 


Supported rates 



7.2.3.8 Probe Request frame format 

The frame body of a management frame of subtype Probe Request contains the information shown in Table 1 1. 

Table 11 — Probe Request frame body 



Order 


Information 


1 


SSID 


2 


Supported rates 



7.2.3.9 Probe Response frame format 

The frame body of a management frame of subtype Probe Response contains the information shown in Table 12. 
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Table 12 — Probe Response frame body 



Order 


Information 


Notes 


I 


Ti mp^tamn 




2 


Beacon interval 




3 


Capability information 




4 


SSID 




5 ■ 


Supported rates 




6 


FH Parameter Set 


The FH Parameter Set information element is present within Probe 
Response frames generated by STAs using frequency-hopping PHYs. 


7 


DS Parameter Set 


The DS Parameter Set information element is present within Probe 
Response frames generated by STAs using direct sequence PHYs. 


8 


CF Parameter Set 


The CF Parameter Set information element is only present within Probe 
Response frames generated by APs supporting a PCR 


9 


IBSS Parameter Set 


The IBSS Parameter Set information element is only present within Probe 
Response frames generated by STAs in an IBSS. 



7.2.3.10 Authentication frame format 

The frame body of a management frame of subtype Authentication contains the information shown in Table 13.* 



Table 13 — Authentication frame body 



Order 


Information 


Notes 


I 


Authentication algorithm number 




2 


Authentication transaction sequence number 




3 


Status code 


The status code information is reserved and set to 0 in 
certain Authentication frames as defined in Table 1 4. 


4 


Challenge text 


The challenge text information is only present in 
certain Authentication frames as defined in Table 1 4. 



Table 14 — Presence of challenge text information 



Authentication 
algorithm 


Authentication 
transaction sequence no. 


Status code 


Challenge text 


Open System 




Reserved 


Not present 


Open System 




Status 


Not present 


Shared Key 




Reserved 


Not present 


Shared Key 




Status 


Present 


Shared Key 




Reserved 


Present 


Shared Key 


4 


Status 


Not present 
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7.2.3.11 Deauthentication 

The frame body of a management frame of subtype Deauthentication contains the information shown in 
Table 15. 



Table 15 — Deauthentication frame body 



Order 


Information 


t 


Reason code 



7.3 Management frame body components 

Within management frames, fixed-length mandatory frame body components are defined as fixed fields; 
variable length mandatory and all optional frame body components are defined as information elements. 

7.3.1 Fixed fields 

7.3.1.1 Authentication Algorithm Number field 

The Authentication Algorithm Number field indicates a single authentication algorithm. The length of the 
Authentication Algorithm Number field is 2 octets. The Authentication Algorithm Number field is illustrated 
in Figure 24. The following values are defined for authentication algorithm number: 

Authentication algorithm number = 0: Open System 
Authentication algorithm number = 1 : Shared Key 
All other values of authentication number are reserved. 

BO B15 

Authentication Algorithm 
Number 

Octets: + 2 ► 

Figure 24 — Authentication Algorithm Number fixed field 

7.3.1.2 Authentication Transaction Sequence Number field 

The Authentication Transaction Sequence Number field indicates the current state of progress through a 
multistep transaction. The length of the Authentication Transaction Sequence Number field is 2 octets. The 
Authentication TransactionJSequence Number field is illustrated in Figure 25. 

BO B15 

Authentication Transaction 
Sequence Number 

Octets: + 2 ► 

Figur 25— Authentication Transaction Sequence Number fixed field 
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7.3.1.3 Beacon Interval field 

The Beacon Interval field represents the number of time units (TUs) between target beacon transmission 
times (TBTTs). The length of the Beacon Interval field is 2 octets. The Beacon Interval field is illustrated in 
Figure 26. 

BO B15 
1 

Beacon Interval 



Octets: < 2 ► 

Figure 26— Beacon Interval fixed field 

7.3.1.4 Capability Information field 

The Capability Information field contains a number of subfields that are used to indicate requested or adver- 
tised capabilities. The length of the Capability Information field is 2 octets. The Capability Information field 
consists of the following subfields: ESS, IBSS, CF-Pollable, CF-Poll Request, and Privacy. The remaining 
part of the Capability Information field is reserved. The format of the Capability Information field is as illus- 
trated in Fisure 27. 



BO 


B1 


B2 


B3 


B4 


B5 


B15 


ESS 


IBSS 


CF 
Pollabte 


CF Poll 
Request 


Privacy 


// 

Reserved 


4 






— " 2 






► 



Figure 27 — Capability Information fixed field 



Each Capability Information subfield is interpreted only in the management frame subtypes for which the 
transmission rules are defined. 

APs set the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Response 
management frames. STAs within an IBSS set the ESS subfield to 0 and the IBSS subfield to I in transmitted 
Beacon or Probe Response management frames. 

STAs set the CF-Pollable and CF-Poll Request subfields in Association and Reassociation Request manage- 
ment frames according to Table 16. 



Table 16 — STA usage of CF-Pollable and CF-Poll Request 



CF-Pollable 


CF-Poll 
request 


Meaning 


0 


0 


STA is not CF-Pollable 


0 


I 


STA is CF-Pollable, not requesting to be placed on the CF-Polling list 


1 


0 


STA is CF-Pollable, requesting to be placed on the CF-Polling list 


1 


1 


STA is CF-Pollable, requesting never to be polled 
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APs set the CF-Pollable and CF-Poll Request subfields in Beacon, Probe Response, Association Response, 
and Reassociation Response management frames according to Table 1 7. An AP sets the CF-Pollable and CF- 
Poll Request subfield values in Association Response and Reassociation Response management frames 
equal to the values in the last Beacon or Probe Response frame that it transmitted. 



Table 17— AP usage of CF-Pollable and CF-Poll Request 



CF-Pollable 


CF-Poll 
Request 


Meaning 


0 


0 


No point coordinator at AP 


0 


t 


Point coordinator at AP for delivery only (no polling) 


1 


0 


Point coordinator at AP for delivery and polling 


1 


1 


Reserved 



APs set the Privacy subfield to 1 within transmitted Beacon, Probe Response, Association Response, and 
Reassociation Response management frames if WEP encryption is required for all data type frames 
exchanged within the BSS. If WEP encryption is not required, the Privacy subfield is set to 0. 

STAs within an IBSS set the Privacy subfield to I in transmitted Beacon or Probe Response management 
frames if WEP encryption is required for all data type frames exchanged within the IBSS. If WEP encryp- 
tion is not required, the Privacy subfield is set to 0. 

7.3.1.5 Current AP Address field 

The Current AP Address field is the MAC address of the AP with which the station is currently associated. The 
length of the Current AP Address field is 6 octets. The Current AP Address field is illustrated in Figure 28. 



BO 647 

1 1 1 1 i 

Current AP Address 
1 1 i i i 

Octets: < 6 + 



Figure 28— Current AP Address fixed field 
7.3.1.6 Listen Interval field 

The Listen Interval field is used to indicate to the A P how often an STA wakes to listen to Beacon manage- 
ment frames. The value of this parameter is the STA's Listen Interval parameter of the MLME-Associ- 
ate.request primitive and is expressed in units of Beacon Interval. The length of the Listen Interval field is 
2 octets. The Listen Interval field is illustrated in Figure 29. 

BO B15 



Listen Interval 



Octets: + 2 ► 

Figure 23— Listen Interval fixed field 
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An AP may use the Listen Interval information in determining the lifetime of frames that it buffers for an STA. 
7.3.1.7 Reason Code field 

This Reason Code field is used to indicate the reason that an unsolicited notification management frame of 
type Disassociation or Deauthentication was generated. The length of the Reason Code field is 2 octets. The 
Reason Code field is illustrated in Figure 30. 

BO B15 
Reason Code 

Octets: * 2 ► 

Figure 30— Reason Code fixed field 

The reason codes are defined in Table 1 8. 



Table 18 — Reason codes 



Reason code 


Meaning 


0 


Reserved 


I 


Unspecified reason 


2 


Previous authentication no longer valid 


3 


Deauthenticated because sending station is leaving (or has left) IBSS or ESS 


4 


Disassociated due to inactivity 


5 


Disassociated because AP is unable to handle all currently associated stations 


6 


Class 2 frame received from nonauthenticated station 


7 


Class 3 frame received from nonassociated station 


8 


Disassociated because sending station is leaving (or has left) BSS 


9 


Station requesting (re)association is not authenticated with responding station 


1 0-65 535 


Reserved 



7.3.1.8 Association ID (AID) field 

The AID field is a value assigned by an AP during association that represents the 1 6-bit ID of a STA. The length 
of the AID field is 2 octets. The AID field is illustrated in Figure 31. 

B0 B15 

i 

" - Association ID (AID) 

1 

Octets: < 2 ► 

Figure 31— AID fixed field 

The value assigned as the Association ID is in the range I-2007 and is placed in the 14 least significant bits 
of the AID field, with the two most significant bits of the AID field each set to 1 (see 7. 1 .3.2). 
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7.3.1.9 Status Code fi Id 

The Status Code field is used in a response management frame to indicate the success or failure of a 
requested operation. The length of the Status Code field is 2 octets. The Status Code field is illustrated in 
Figure 32. 

BO B15 

Status Code 

t 

Octets: ^ 2 > 

Figure 32— Status Code fixed field 

If an operation is successful, then the status code is set to 0. If an operation results in failure, the status code 
indicates a failure cause. The failure cause codes are defined in Table 19. 



Table 19 — Status codes 



Status code 


Meaning 


0 


Successful 


I 


Unspecified failure 


2-9 


Reserved 


10 


Cannot support all requested capabilities in the Capability Information field 


11 


Reassociation denied due to inability to confirm that association exists 


12 


Association denied due to reason outside the scope of this standard 


13 


Responding station does not support the specified authentication algorithm 


14 


Received an Authentication frame with authentication transaction sequence number 
out of expected sequence 


15 


Authentication rejected because of challenge failure 


16 


Authentication rejected due to timeout waiting for next frame in sequence 


17 


Association denied because AP is unable to handle additional associated stations 


18 


Association denied due to requesting station not supporting all of the data rates in the 
BSS Basic Rate Set parameter 


19-65 535 


Reserved 



7.3.1.10 Timestamp field 

This field represents the value of the TSFTIMER (see 1 1. 1) of a frame's source. The length of the Timestamp 
field is 8 octets. The Timestamp field is illustrated in Figure 33. 

B0 B63 
1 1 1 1 1 1 1 

Timestamp 

1 1 1 i i i i 

Octets: * " 3 * 

Figur 33 — Timestamp fixed field 
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Elements are defined to have a common general format consisting of a I octet Element ID field, a 1 octet 
length field, and a variable-length element-specific information field. Each element is assigned a unique 
Element ID as defined in this standard. The Length field specifies the number of octets in the Information 
field. See Fiaure 34. 



Element ID 



Length 



~i 1 1 r 

Information 
J I I L 



Octets: 



1 



length 



Figure 34 — Element format 

The set of valid elements is defined in Table 20. 

Table 20— Element IDs 



Information element 


Element ID 


SSID 


0 


Supported rates 


1 


FH Parameter Set 


2 


DS Parameter Set 


3 


CF Parameter Set 


4 


TIM 


5 


IBSS Parameter Set 


6 


Reserved 


7-15 


Challenge text 


16 


Reserved for challenge text extension 


17-31 


Reserved 


32-255 



7.3.2.1 Service Set Identity (SSID) element 

The SSID element indicates the identity of an ESS or IBSS. See Figure 35. 



Element ID 



Length 



SSID 



Octets: 



0-32 



Figure 35— SSID element format 



The length of the SSID information field is between 0 and 32 octets. A 0 length information field indicates 
the broadcast SSID, 

7.3.2.2 Supported Rates element 

The Supported Rates element specifies the rates in the Operational Rate Set as described in the 
MLME_Join.request and MLME_Start.request primitives. The information field is encoded as I to 8 octets 
where each octet describes a single supported rate in units of 500 kbit/s. 
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Within Beacon, Probe Response, Association Response, and Reassociation Response management frames, 
each supported rate belonging to the BSSBasicRateSet, as defined in 10.3.10.1, is encoded as an octet with 
the msb (bit 7) set to 1 (e.g., a 1 Mbit/s rate belonging to the BSSBasicRateSet is encoded as X'82'). Rates 
not belonging to the BSSBasicRateSet are encoded with the msb set to 0 (e.g., a 2 Mbit/s rate not belonging 
to the BSSBasicRate Set is encoded as X'04'). The msb of each Supported Rate octet in other management 
frame types is ignored by receiving STAs. 



BSSBasicRateSet information in Beacon and Probe Response management frames is used by STAs in order to 
avoid associating with a BSS if they do not support all the data rates in the BSSBasicRateSet. See Figure 36. 



Element ID 



Length 



Supported Rates 



Octets: 



1-8 ■ 



Figure 36 — Supported rates element format 



7.3.2.3 FH Parameter Set element 

The FH Parameter Set element contains the set of parameters necessary to allow synchronization for STAs. 
using a frequency-hopping (FH) PHY. The information field contains Dwell Time, Hop Set, Hop Pattern, 
and Hop Index parameters. The total length of the information field is 5 octets. See Figure 37. 



Element ID 


Length 


Dwell Time (TU) 


Hop Set 


Hop Pattern 


Hop Index 




« 1 ► 


< 2 > 


+ 1 ► 


+ 1 ► 





Figure 37 — FH Parameter Set element format 



The Dwell Time field is 2 octets in length and contains the dwell time in TU. 

The Hop Set field identifies the current set (dotl lCurrentSet) of hop patterns and is a single octet. 

The Hop Pattern field identifies the current pattern (dotl lCurrentPattern) within a set of hop patterns and is 
a single octet. 

The Hop Index field selects the current index (dotl ICurrentlndex) within a pattern and is a single octet. 
The description of the attributes used in this subclause can be found in 14.8.2. 1 . 

7.3.2.4 DS Parameter Set element 

The DS Parameter Set element contains information to allow channel number identification for STAs using a 
direct sequence spread spectrum (DSSS) PHY. The information field contains a single parameter containing 
the dotl ICurrentChanneiNumber (see 15.4.6.2 for values). The length of the dotl ICurrentChannelNumber 
parameter is I octet. See Figure 38. 

7.3.2.5 CF Parameter Set element 

The CF Parameter Set element contains the set of parameters necessary to support the PCF. The information 
field contains the CFPCount, CFPPeriod, CFPMaxDuration, and CFPDurRemaining fields. The total length 
of the information field is 6 octets. See Figure 39. 
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Element ID 


Length 


Current 




Channel 


<« 1 ► 


« — 1 ► 





Figure 38— DS Parameter Set element format 



Element ID 


Length 


CFP 
Count 


CFP 
Period 


CFP MaxDuration 
(TU) 


CFP DurRemaining 
(TU) 




M 1 ► 


< 1 


« 1 ► 


< 2 ► 


< 2 ► 



Figure 39— CF Parameter Set element format 

CFPCount indicates how many DTIMs (including the current frame) appear before the next CFP start. A 
CFPCount of 0 indicates that the current DTIM marks the start of the CFP. 



CFPPeriod indicates the number of DTIM intervals between the start of CFPs. The value is an integral 
number of DTIM intervals. 



CFPMaxDuration indicates the maximum duration, in TU, of the CFP that may be generated by this PCF. 
This value is used by STAs to set their NAV at the TBTT of beacons that begin CFPs. 

CFPDurRemaining indicates the maximum time, in TU, remaining in the present CFP, and is set to zero in 
CFP Parameter elements of beacons transmitted during the contention period. The value of CFPDurRemain- 
ing is referenced to the immediately previous TBTT. This value is used by all STAs to update their NAVs 
during CFPs. 

7.3.2.6 TIM 

The TIM element contains four fields: DTIM Count, DTIM Period, Bitmap Control, and Partial Virtual 
Bitmap. See Figure 40. 



Element ID 


Length 


DTIM 
Count 


DTIM 
Period 


Bitmap 
Control 


Partial Virtual Bitmap 



Octets: < 1 1 — 1 1 ►<« 1 X 1- 251 ► 

Figure 40— TIM element format 



The Length field for this element indicates the length of the information field, which is constrained as 
described below. 

The DTIM Count field indicates how many beacons (including the current frame) appear before the next 
DTIM. A DTIM Count of 0 indicates that the current TIM is a DTIM. The DTIM count field is a single octet. 

The DTIM Period field indicates the number of Beacon intervals between successive DTIMs. If all TIMs are 
DTIMs, the DTIM Period field has the value 1. The DTIM Period value 0 is reserved. The DTIM period field 
is a single octet. 

The Bitmap Control field is a single octet. Bit 0 of the field contains the Traffic Indicator bit associated with 
Association ID 0. This bit is set to 1 in TIM elements with a value of 0 in the DTIM Count field when one or 
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more broadcast or multicast frames are buffered at the AP. The remaining 7 bits of the field form the Bitmap 
Offset. 

The traffic- indication virtual bitmap, maintained by the AP that generates a TIM, consists of 2008 bits, and is 
organized into 25 1 octets such that bit number N(0 <N< 2007) in the bitmap corresponds to bit number 
OVmod 8) in octet number [N 1 8 J where the low-order bit of each octet is bit number 0, and the high order 
bit is bit number 7. Each bit in the traffic-indication virtual bitmap corresponds to traffic buffered for a 
specific station within the BSS that the AP is prepared to deliver at the time the beacon frame is transmitted. 
Bit number /V is 0 if there are no directed frames buffered for the station whose Association ID is K If any 
directed frames for that station are buffered and the AP is prepared to deliver them, bit number N in the traf- 
fic-indication virtual bitmap is 1 . A PC may decline to set bits in the TIM for CF-Pollable stations it does not 
intend to poll (see 11.2.1.5). 



The Partial Virtual Bitmap field consists of octets numbered N\ through N2 of the traffic indication virtual 
bitmap, where JV1 is the largest even number such that bits numbered 1 through (N\ x 8) - 1 in the bitmap 
are all 0 and N2 is the smallest number such that bits numbered (N2 + I) x 8 through 2007 in the bitmap are 
all 0. In this case, the Bitmap Offset subfield value contains the number LM/2J, and the Length field will be 
setto(yV2-An) + 4. 



In the event that all bits other than bit 0 in the virtual bitmap are 0, the Partial Virtual Bitmap field is encoded 
as a single octet equal to 0, and the Bitmap Offset subfield is 0. 



7.3.2.7 IBSS Parameter Set element 



The IBSS Parameter Set element contains the set of parameters necessary to support an IBSS. The informa- 
tion field contains the ATIM Window parameter. See Figure 4 1 . 



Element ID 



Length 



ATIM Window 



Octets: < 1 1 



Figure 41— IBSS Parameter Set element format 



The ATIM Window field is 2 octets in length and contains the ATIM Window length in TU. 
7.3.2.8 Challenge Text element 



The Challenge Text element contains the challenge text within Authentication exchanges. The element infor- 
mation field length is dependent upon the authentication algorithm and the transaction sequence number as 
specified in 8. 1 . See Figure 42. 



Element ID 



Length 



Challenge Text 



Octets: 



1 



■ 1-253 ■ 



Figure 42— Challenge Text element f rmat 
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8. Authentication and privacy 
8.1 Authentication services 

IEEE 802.11 defines two subtypes of authentication serv ice: Open System and Shared Key. The subtype 
invoked is indicated in the body of authentication management frames. Thus authentication frames are self- 
identifying with respect to authentication algorithm. All management frames of subtype Authentication shall 
be unicast frames as authentication is performed between pairs of stations (i.e., multicast authentication is 
not allowed). Management frames of subtype Deauthentication are advisory, and may therefore be sent as 
group-addressed frames. 

A mutual authentication relationship shall exist between two stations following a successful authentication 
exchange as described below. Authentication shall be used between stations and the AP in an infrastructure 
BSS. Authentication may be used between two STAs in an IBSS. 

8.1.1 Open System authentication 

Open System authentication is the simplest of the available authentication algorithms. Essentially it is a null 
authentication algorithm. Any STA that requests authentication with this algorithm may become authenti- 
cated if dotl l AuthenticationType at the recipient station is set to Open System authentication. Open System 
authentication is not required to be successful as a STA may decline to authenticate with any particular other 
STA. Open System authentication is the default authentication algorithm. 

Open System authentication involves a two-step authentication transaction sequence. The first step in the 
sequence is the identity assertion and request for authentication. The second step in the sequence is the 
authentication result. If the result is "successful " the STAs shall be mutually authenticated. 

8.1.1.1 Open System authentication (first frame) 

— Message type: Management 

— Message subtype: Authentication 

— Information items: 

• Authentication Algorithm Identification - "Open System" 

• Station Identity Assertion (in SA field of header) 

• Authentication transaction sequence number = 1 

• Authentication algorithm dependent information (none) 

— Direction of message: From authentication initiating STA to authenticating STA 

8.1.1.2 Open System authentication (final frame) 

— Message type: Management 

— Message subtype: Authentication 

— Information items: 

• Authentication Algorithm Identification = "Open System" 

• Authentication transaction sequence number - 2 

• Authentication algorithm dependent information (none) 

• The result of the requested authentication as defined in 7.3.1 .9 

— Direction of message: From authenticating STA to initiating STA 

If dotl 1 AuthenticationType does not include the value "Open System," the result code shall not take the 
value "successful." 
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8.1.2 Shared Key authentication 

Shared Key authentication supports authentication of STAs as either a member of those who know a shared 
secret key or a member of those who do not. IEEE 802. 1 1 Shared Key authentication accomplishes this 
without the need to transmit the secret key in the clear; however, it does require the use of the WEP privacy 
mechanism. Therefore, this authentication scheme is only available if the WEP option is implemented. Addi- 
tionally, the Shared Key authentication algorithm shall be implemented as one of the 
dotl I AuthenticationAigorithms at any STA where WEP is implemented. 

The required secret, shared key is presumed to have been delivered to participating STAs via a secure chan- 
nel that is independent of IEEE 802.1 1. This shared key is contained in a write-only MIB attribute via the 
MAC management path. The attribute is write-only so that the key value remains internal to the MAC. 

During the Shared Key authentication exchange, both the challenge and the encrypted challenge are 
transmitted. This facilitates unauthorized discovery of the pseudorandom number (PRN) sequence for the 
key/IV pair used for the exchange. Implementations should therefore avoid using the same key/I V pair for 
subsequent frames. 

A STA shall not initiate a Shared Key authentication exchange unless its dotl I Privacy Optionlmplemented 
attribute is "true." 

In the following description, the STA initiating the authentication exchange is referred to as the requester, 
and the STA to which the initial frame in the exchange is addressed is referred to as the responder. 

8.1.2.1 Shared Key authentication (first frame) 

— Message type: Management 

— Message subtype: Authentication 

— Information Items: 

• Station Identity Assertion (in SA field of header) 

• Authentication Algorithm Identification = "Shared Key" 

• Authentication transaction sequence number = 1 

• Authentication algorithm dependent information (none) 

— Direction of message: From requester to responder 

8.1 .2.2 Shared Key authentication (second frame) 

Before sending the second frame in the Shared Key authentication sequence, the responder shall use WEP to 
generate a string of octets that shall be used as the authentication challenge text. 

— Message type: Management 

— Message subtype: Authentication 

— Information Items: 

• Authentication Algorithm Identification = "Shared Key" 

• Authentication transaction sequence number = 2 

• Authentication algorithm dependent information = the authentication result. 

• The result of the requested authentication as defined in 7. '3 . 1 .9 

If the status code is not "successful," this shall be the last frame of the transaction sequence. If 
the status code is not "successful," the content of the challenge text field is unspecified. 

If the status code is "successful " the following additional information items shall have valid con- 
tents: 

Authentication algorithm dependent information = challenge text. 
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This field shall be of fixed length of 1 28 octets. The field shall be filled with octets gener- 
ated by the WEP pseudo-random number generator (PRNG). The actual value of the chal- 
lenge field is unimportant, but the value shall not be a single static value. The key and IV 
used when generating the challenge text are unspecified because this key/IV value does 
not have to be shared and does not affect interoperability. 

— Direction of message: From responder to requester 

8.1.2.3 Shared Key authentication (third frame) 

The requester shall copy the challenge text from the second frame into the third frame. The third frame shall 
be transmitted after encryption by WEP, as defined in 8.2.3, using the shared secret key. 

— Message type: Management 

— Message subtype: Authentication 

— Information Items: 

• Authentication Algorithm Identification = "Shared Key" 

• Authentication transaction sequence number = 3 

• Authentication algorithm dependent information = challenge text from sequence two frame 

— Direction of message: From requester to responder 

This frame shall be encrypted as described below. 

8.1.2.4 Shared Key authentication (final frame) 

The responder shall attempt to decrypt the contents of the third frame in the authentication sequence as 
described below. If the WEP ICV check is successful, the responder shall then compare the decrypted con- 
tents of the Challenge Text field to the challenge text that was sent in Frame 2 of the sequence. If they are the 
same, then the responder shall respond with a successful status code in Frame 4 of the sequence. If the WEP 
ICV check fails, the responder shall respond with an unsuccessful status code in Frame 4 of the sequence as 
described below. 

— Message type: Management 

— Message subtype: Authentication 

— Information Items: 

• Authentication Algorithm Identification = "Shared Key" 

• Authentication transaction sequence number = 4 

• Authentication algorithm dependent information = the authentication result 

The result of the requested authentication. 

This is a fixed length item with values "successful" and "unsuccessful 

— Direction of message: From responder to requester 

8.2 The Wired Equivalent Privacy (WEP) algorithm 
8.2.1 Introduction 

Eavesdropping is a familiar problem to users of other types of wireless technology. IEEE 802.1 1 specifies a 
wired LAN equivalent data confidentiality algorithm. Wired equivalent privacy is defined as protecting 
authorized users of a wireless LAN from casual eavesdropping. This service is intended to provide function- 
ality for the wireless LAN equivalent to that provided by the physical security attributes inherent to a wired 
medium. 

Data confidentiality depends on an external key management service to distribute data enciphering/decipher- 
ing keys. The IEEE 802.1 1 standards committee specifically recommends against running an IEEE 802.1 1. 
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LAN with privacy but without authentication. While this combination is possible, it leaves the system open 
to significant security threats. 

8.2.2 Properties of the WEP algorithm 

The WEP algorithjTbhas the following properties: 

— ft is reasonably strong: The security afforded by the algorithm relies on the difficulty of discovering 
the secret key through a brute-force attack. This in turn is related to the length of the secret key and 
the frequency of changing keys. WEP allows for the changing of the key (k) and frequent chanainij 
of the IV. 

— // is self-synchronizing: WEP is self-synchronizing for each message. This property is critical for a 
data-link level encryption algorithm, where "best effort'' delivery is assumed and packet loss rates 
may be high. 

— It is efficient: The WEP algorithm is efficient and may be implemented in either hardware or soft- 
ware. 

— It may be exportable: Every effort has been made to design the WEP system operation so as to maxi- 
mize the chances of approval, by the U.S. Department of Commerce, of export from the U.S. of 
products containing a WEP implementation. However, due to the legal and political climate toward 
cryptography at the time of publication, no guarantee can be made that any specific IEEE 802.11 
implementations that use WEP will be exportable from the USA. 

— // is optional: The implementation and use of WEP is an IEEE 802. 1 1 option. 

8.2.3 WEP theory of operation 

The process of disguising (binary) data in order to hide its information content is called encryption (denoted 
by E) (see [B4]). Data that is not enciphered is called plaintext (denoted by P) and data that is enciphered is 
called ciphertext (denoted by Q. The process of turning ciphertext back into plaintext is called decryption 
(denoted by D). A cryptographic algorithm, or cipher, is a mathematical function used for enciphering or 
deciphering data. Modern cryptographic algorithms use a key sequence (denoted by k) to modify their out- 
put. The encryption function E operates on P to produce C: 

E k (P) = C 

In the reverse process, the decryption function D operates on C to produce P: 
D k (C) = P 

As illustrated in Figure 43, note that if the same key can be used for encryption and decryption then 
D k (E k (P)) = P 



Plaintext 



Key 

\ 



Key Management Service 



Ciphertext 
Encryption 1 Decryption 



Original 
Plaintext 



► Eavesdropper 
Figure 43 — A confidential data channel 



The WEP algorithm is a form of electronic code book in which a block of plaintext is bitwise XORed with a 
pseudorandom key sequence of equal length. The key sequence is generated by the WEP algorithm. 
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Referring to Figure 44 and viewing from left to right, encipherment begins with a secret key- that has been 
distributed to cooperating STAs by an external key management service. WEP is a symmetric algorithm in 
which the same key is used for encipherment and decipherment. 



Initialization 
Vector (IV) - 

Secret Key - 

Plaintext 





Seed 


WEP 


II 




PRNG 



Integrity Algorithm 




Integrity Check Value (ICV) 
Figure 44 — WEP encipherment block diagram 



Message 



The secret key is concatenated with an initialization vector (IV) and the resulting seed is input to a PRNG. The 
PRNG outputs a key sequence k of pseudorandom octets equal in length to the number of data octets that are to 
be transmitted in the expanded MPDU plus 4 [since the key sequence is used to protect the integrity check value 
(ICV) as well as the data]. Two processes are applied to the plaintext MPDU. To protect against unauthorized 
data modification, an integrity algorithm operates on P to produce an ICV. Encipherment is then accomplished 
by mathematically combining the key sequence with the plaintext concatenated with the ICV. The output of the 
process is a message containing the IV and ciphertext. 

The WEP PRNG is the critical component of this process, since it transforms a relatively short secret key 
into an arbitrarily long key sequence. This greatly simplifies the task of key distribution, as only the secret 
key needs to be communicated between STAs. The IV extends the useful lifetime of the secret key and pro- 
vides the self-synchronous property of the algorithm. The secret key remains constant while the IV changes 
periodically. Each new IV results in a new seed and key sequence, thus there is a one-to-one correspondence 
between the IV and k. The IV may be changed as frequently as every MPDU and, since it travels with the 
message, the receiver will always be able to decipher any message. The IV is transmitted in the clear since it 
does not provide an attacker with any information about the secret key, and since its value must be known by 
the recipient in order to perform the decryption. 

When choosing how often to change IV values, irnplementors should consider that the contents of some 
fields in higher-layer protocol headers, as well as certain other higher- layer information, is constant or 
highly predictable. When such information is transmitted while encrypting with a particular key and IV, an 
eavesdropper can readily determine portions of the key sequence generated by that (key, IV) pair. If the same 
(key, IV) pair is used for successive MPDUs, this effect may substantially reduce the degree of privacy con- 
ferred by the WEP algorithm, allowing an eavesdropper to recover a subset of the user data without any 
knowledge of the secret key. Changing the IV after each MPDU is a simple method of preserving the effec- 
tiveness of WEP in this situation. 



The WEP algorithm is applied to the frame body of an MPDU. The (IV, frame body, ICV) triplet forms the 
actual data to be sent in the data frame. 

For WEP protected framesjhe first four octets of the frame body contain the IV field for the MPDU. This 
field is defined in 8.2.5. The PRNG seed is 64 bits. Bits 0 through 23 of the IV correspond to bits 0 through 
23 of the PRNG seed, respectively. Bits 0 through 39 of the secret key correspond to bits 24 through 63 of 
the PRNG seed, respectively. The bit and octet numbering conventions in 7.1.1 apply to the PRNG seed, 
secret key, and IV. The numbering of the octets of the PRNG seed corresponds to that of the RC4 key. The 
IV is followed by the MPDU, which is followed by the ICV The WEP ICV is 32 bits. The WEP Integrity 
Check algorithm is CRC-32, as defined in 7. 1 .3.6. 



As stated previously, WEP combines k with P using bitwise XOR. 
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Referring to Figure 45 and viewing from left to right, decipherment begins with the arrival of a message. The 
IV of the incoming message shall be used to generate the key sequence necessary to decipher the incoming 
message. Combining the ciphertext with the proper key sequence yields the original plaintext and ICV. Cor- 
rect decipherment shall be verified by performing the integrity check algorithm on the recovered plaintext 
and comparing the output ICV to the ICV transmitted with the message. If ICV' is not equal to ICV, the 
received MPDU is in error and an error indication is sent to MAC management. MSDUs with erroneous 
MPDUs (due to inability to decrypt) shall not be passed to LLC. 



Secret Key- 



Ciphertesrt 



Seed 



WEP 
PRNG 



Key Sequence 



Plaintext 




L> ) Integrity Algorithm) ICV * 



ICV 




ICV = ICV? I 



Message 

Figure 45 — WEP decipherment block diagram 

8.2.4 WEP algorithm specification 

WEP uses the RC4 PRNG algorithm from RSA Data Security, Inc. 6 

8.2.5 WEP Frame Body expansion 

Figure 46 shows the encrypted Frame Body as constructed by the WEP algorithm 

Encrypted (Note) — — 
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Pad iKevID 
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NOTE - The encypherment process has expanded the original Frame Body by 8 octets, 4 for the IV 
field and 4 for the ICV. The ICV is calculated on the data field only. 

Figure 46— Construction of expanded WEP Frame Body 



The WEP ICV shall be a 32-bit field containing the CRC-32, as defined in 7. 1.3.6 calculated over the Data 
(PDU) field as depicted in Figure 46. The expanded Frame Body shall include a 32-bit IV field immediately 
preceding the original Frame Body. This field shall contain three subfields: a three-octet field that contains 
the initialization vector, a 2-bit key ID field, and a 6-bit pad field. The ordering conventions defined in 7.1.1 
apply to the IV fields and its subfields and to the ICV field. The key ID subfield contents select one of four 



6 Dctails of the RC4 algorithm are available from RSA. Please contact RSA for algorithm details and the uniform RC4 licensee terms 
that RSA offers to anyone wishing to use RC4 for the purpose of implementing the IEEE 802.1 1 WEP option. If necessary, contact the 
IEEE Standards Department Intellectual Property Rights Administrator for details on how to communicate with RSA. 
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possible secret key values for use in decrypting this Frame Body. Interpretation of these bits is discussed fur- 
ther in 8.3.2. The contents of the pad subfield shall be zero. The key ID occupies the two msb of the last octet 
of the IV field, while the pad occupies the six lsb of this octet. 

The WEP mechanism is invisible to entities outside the IEEE 802. 1 1 MAC data path. 
8.3 Security-Related MIB attributes 

The IEEE 802.11 security mechanisms are controlled via the MAC management path and related MIB 
attributes. This subclause gives an overview of the security -related MIB attributes and how they are used. 
For details of the MIB attribute definitions, refer to 1 1.4. 

8.3.1 Authentication-Related MIB attributes 

The type of authentication invoked when authentication is attempted is controlled by the AuthenticationType 
parameter to the ML ME- AUTHENTIC ATE.request primitive. The type of authentication request that may 
be accepted by a STA is controlled by the MIB attribute dotl 1 AuthenticationType. The type of authentica- 
tion is selected from the following set of values: 

— Open System 

— Shared Key 

All other values are reserved. The numeric encoding of these values is given in 7.3. 1.1. 

8.3.2 Privacy-Related MIB attributes 

WEP invocation is controlled by the parameters passed to the MLME-AUTHENTICATE.request primitive 
as well as a number of MIB attributes. An overview of the attributes and their usage is given in this 
subclause. All MIB attributes that hold WEP keys are externally write-only; the contents shall not be read- 
able via MAC management SAPs. See 1 1 .4 for the formal MIB attribute definitions. 

The boolean variable dotl 1 Privacy Invoked shall be set to "false" to prevent the STA from transmitting 
MPDUs of type Data with the WEP subfield of the Frame Control field set to 1. It does not affect MPDU or 
MMPDU reception. 

The default value for all WEP keys shall be null. Note that encrypting a frame using WEP with a null key is 
not the same as failing to encrypt the frame. Any request to encrypt a frame with a null key shall result in the 
MSDU being discarded and an MA-UNIDATA- STATUS. indication with a transmission status indicating 
that the frame may not be encrypted with a null key. Decrypting a frame whose WEP subfield is set to 1 
involves stripping the IV, and checking the ICV against the calculated ICV value computed over the data 
contained in the MPDU. 

To support shared key configurations, the MIB contains a four-element vector called 
"dotl 1 WEPDefaultKeys." The default value for each element of this vector is null. These elements contain 
the default keys to be used with WEP. 

An additional attribute called "dotl 1 WEPDefaultKeylD" is an integer. When set to a value of 0, 1, 2, or 3, 
MPDUs transmitted with the WEP subfield of the Frame Control field set to 1 shall be encrypted using the 
first, second, third, or fourth element, respectively, from dotl 1 WEPDefaultKeys, unless the frame has an 
individual RA and a key mapping exists for the RA of the frame. On receive, the incoming MPDU shall be 
decrypted using the element from dotl 1 WEPDefaultKeys specified by the received key ID field, unless the 
frame has an individual RA and a key mapping exists for the TA of the frame. The value in the transmitted 
key ID field shall be zero in all cases except when dotl 1 WEPDefaultKeylD is used to encrypt a frame and is 
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set to a value of I, 2, or 3, in which case the transmitted key ID field shall contain the value of 
dotl IWEPDefaultKeylD. 

When the boolean attribute aExcludeUnencrypted is set to True, MPDUs of type Data received by the STA 
with the WEP subfield of the Frame Control field equal to zero shall not be indicated at the MAC service 
interface. When aExcludeUnencrypted is set to True, only MSDUs that have been decrypted successfully 
shall be indicated at the MAC service interface. 

IEEE 802. 1 1 does not require that the same WEP key be used for all STAs. The MIB supports the ability to 
share a separate WEP key for each RA/TA pair. Key mapping is supported by a MIB attribute that is an array 
called "dot I l WEPKeyMappings." dotl 1 WEPKeyMappings contains zero or one entry for each MAC 
address, up to an implementation-defined maximum number of entries identified by 
dotl lWEPKeyMappingLength, and contains two fields for each entry: a boolean "WEPOn" and the corre- 
sponding WEPKey. In an infrastructure BSS, the AP's WEPOn value in the entry in its 
dotl 1 WEPKeyMapping table corresponding to a STA's MAC address shall not be set to True for a STA if 
that STA has not successfully initiated and completed an authentication sequence using an authentication 
type other than "Open System" The default value for all WEPOn fields is False, dotl 1 WEPKeyMappings 
shall be indexed by either RA or TA addresses (since WEP is applied only to the wireless link), as described 
below. When an entry in the table exists for a particular MAC address, the values in the 
dotl 1 WEPKeyMappings attribute shall be used instead of the dotl IWEPDefaultKeylD and 
dotl I WEPDefaultKeys variables. 

The minimal value of dotl 1 WEPKey MappingLength shall be 10. This value represents a minimum capabil- 
ity that may be assumed for any STA implementing the WEP option. 

When transmitting a frame of type Data, the values of dotl 1 Privacy Invoked, dotl 1 WEPKeyMappings, 
dotl 1 WEPDefaultKeys, and dotl IWEPDefaultKeylD in effect at an unspecified time between receipt by the 
MAC of the MAUNITDATA.request primitive and the time of transmission of that frame shall be used * 
according to the following decision tree: 

if dot! 1 Privacylnvoked is "false" 

the MPDU is transmitted without encryption 

else 

if (the MPDU has an individual RA and 
there is an entry in dotl 1 WEPKeyMappings for that RA) 
if that entry has WEPOn set to "false" 

the MPDU is transmitted without encryption 

else 

if that entry contains a key that is null 

discard the entire MSDU and generate an 
MA-UNITDATA-STATUS. indication primitive to 
notify LLC that the MSDU was undeliverable due to 
a null WEP key 

else 

encrypt the MPDU using that entry's key, setting the key ID 
• « . subfield of the IV field to zero 

else 

if (the MPDU has a group RA and the Privacy subfield 

of the Capability Information field in this BSS is set to 0) 
the MPDU is transmitted without encryption 

else 

if dotl 1 WEPDefaultKeys[dotl IWEPDefaultKeylD] is null 
discard the MSDU and generate an 
MA-UNITDATA-STATUS. indication primitive to 
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notify LLC that the entire MSDU was undeliverable 
due to a null WEP key 

else 

encrypt the MPDU using 

dot 1 I WEPDefaultKeys[dotl lWEPDefaultKeylD], 
setting the Key ID subfield of the IV field to 
dotllWEPDefaultKeylD 

When receiving a frame of type Data, the values of dot 1 1 Privacy Option Implemented, 
dotllWEPKeyMappings, dotll WEPDefaultKeys, dotllWEPDefaultKeylD, and aExcludeUnencrypted in 
effect at the time the PHY-RXSTART.indication primitive is received by the MAC shall be used according to 
the following decision tree: 

if the WEP subfield of the Frame Control Field is zero 
if aExcludeUnencrypted is "true" 

discard the frame body without indication to LLC and increment 
dotl 1 WEPExcludedCount 

else 

receive the frame without decryption 

else 

if dotl 1 PrivacyOptionlmplemented is "true" 
if (the MPDU has individual RA and 

there is an entry in dotl 1 WEP Key Mappings matching the MPDU's TA) 
if that entry has WEPOn set to "false" 

discard the frame body and increment 
dotl 1 WEPUndecryptableCount 

else 

if that entry contains a key that is null 

discard the frame body and increment 
dotl 1 WEPUndecryptableCount 

else 

attempt to decrypt with that key, incrementing 
dotl 1 WEPICVErrorCount if the ICV check fails 

else 

if dotl 1 WEPDefaultKeys[keyID] is null 

discard the frame body and increment 
dotl 1 WEPUndecryptableCount 

else 

attempt to decrypt with dotl 1 WEPDefaultKeys[keyID], 
incrementing dot 1 1 WEPICVErrorCount if the ICV check fails 

else 

discard the frame body and increment dotl 1 WEPUndecryptableCount 

When transmitting a frame of type Management, subtype Authentication with an Authentication Transaction 
Sequence Number field value of 2, the MAC shall operate according to the following decision tree: 

if dotl 1 PrivacyOptionlmplemented is "false" 

the MMPDU is transmitted with a sequence 

of zero octets in the Challenge Text field and a Status Code value of 1 3 

else 

the MMPDU is transmitted with a sequence of 128 octets generated using the 
WEP PRNG and a key whose value is unspecified and beyond the scope of this 
standard and a randomly chosen IV value (note that this will typically be selected 
by the same mechanism for choosing IV values for transmitted data MPDUs) 
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in the Challenge Text field and a status code value of 0 (the IV used is 
immaterial and is not transmitted). Note that there are cryptographic issues 
involved in the choice of key/I V for this process as the challenge text is sent 
unencrypted and therefore provides a known output sequence from the PRNG. 

When receiving a frame of type Management, subtype Authentication with an Authentication Transaction 
Sequence Number field value of 2, the MAC shall operate according to the following decision tree: 

if the WEP subfield of the Frame Control field is 1 
respond with a status code value of 1 5 

else 

if dot 1 1 PrivacyOptionlmplemented is "true" 

if there is a mapping in dotl 1 WEPKeyMappings matching the MSDU's TA 
if that key is null 

respond with a frame whose Authentication Transaction 
Sequence Number field is 3 that contains the appropriate 
Authentication Algorithm Number, a status code value of 
1 5 and no Challenge Text field, without encrypting the 
contents of the frame 

else 

respond with a frame whose Authentication Transaction 
Sequence Number field is 3 that contains the appropriate 
Authentication Algorithm Number, a status code value of 
0 and the identical Challenge Text field, encrypted using 
that key, and setting the key ID subfield in the IV field to 0 

else 

if dotl 1 WEPDefaultKeys[dotl lWEPDefaultfCeylD] is null 

respond with a frame whose Authentication Transaction 
Sequence Number field is 3 that contains the appropriate 
Authentication Algorithm Number, a status code value of 
1 5 and no Challenge Text field, without encrypting the 
contents of the frame 

else 

respond with a frame whose Authentication Transaction 
Sequence Number field is 3 that contains the appropriate 
Authentication Algorithm Number, a status code value of 0 
and the identical Challenge Text field, encrypted using 
dotl l\VEPDefaultKeys[dotl lWEPDefaultKeylD], setting the 
key ID subfield in the IV field to dotl lWEPDefaultKeylD 

else 

respond with a frame whose Authentication Transaction 
Sequence Number field is 3 that contains the appropriate Authentication 
Algorithm Number, a status code value of 1 3 and no Challenge Text 
field, without encrypting the contents of the frame 



When receiving a frame of type Management, subtype Authentication with an Authentication Transaction 
Sequence Number field value of 3, the MAC shall operate according to the following decision tree: 

if the WEP subfield of the Frame Control field is zero 
respond with a status code value of 1 5 

else 

if dotl 1 PrivacyOptionlmplemented is '"true" 

if there is a mapping in dotl 1 WEPKeyMappings matching the MSDU's TA 
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if that key is null 

respond with a frame whose Authentication Transaction 
Sequence Number field is 4 that contains the appropriate 
Authentication Algorithm Number, and a status code value 
of 1 5 without encrypting the contents of the frame 

else 

attempt to decrypt with that key, incrementing 

dotl 1 WEPICVErrorCount and responding with a status code value 

of 15 if the ICV check fails 

else 

if dotl 1 WEPDefaultKeysfkeylD] is null 

respond with a frame whose Authentication Transaction 
Sequence Number field is 4 that contains the appropriate 
Authentication Algorithm Number, and a status code value 
of 1 5 without encrypting the contents of the frame 

else 

attempt to decrypt with dotl 1 WEPDefaultKeysfkeylD], 
incrementing dotl 1 WEPICVErrorCount and responding with 
a status code value of 1 5 if the ICV check fails 

else 

respond with a frame whose Authentication Transaction Sequence Number 
field is 4 that contains the appropriate Authentication Algorithm Number, 
and a status code value of 15 

The attribute dot 11 Privacy Invoked shall not take the value "true" if the attribute 
dot 1 1 PrivacyOptionlmplemented is "false." Setting the attribute dotl IWEPKey Mappings to a value that 
includes more than dotl 1 WEPKeyMappingLength entries is illegal and shall have an implementation-specific 
effect on the operation of the privacy service. Note that dotl IWEPKey Mappings may contain between zero 
and dotl 1 WEPKeyMappingLength entries, inclusive. 

It is recommended that the values of the attributes in the aPrivacygrp not be changed during the authentica- 
tion sequence as unintended operation may result. 
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9. MAC sublayer functional description 

The MAC functional description is presented in this clause. The architecture of the MAC sublayer, including 
the distributed coordination function (DCF), the point coordination function (PCF), and their coexistence in an 
IEEE 802. 1 1 LAN are introduced in 9.1. These functions are expanded on in 9.2 and 9.3, and a complete func- 
tional description of each is provided. Fragmentation and defragmentation are covered in 9.4 and 9.5. Multirate 
support is addressed in 9.6. The allowable frame exchange sequences are listed in 9.7. Finally, a number of 
additional restrictions to limit the cases in which MSDUs are reordered or discarded are described in 9.8. 



9.1 MAC architecture 



The MAC architecture can be described as shown in Figure 47 as providing the PCF throuah the services of 
the DCF. 
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Figure 47 — MAC architecture 
9.1.1 Distributed coordination function (DCF) 



The fundamental access method of the IEEE 802.1 1 MAC is a DCF known as carrier sense multiple access 
with collision avoidance (CSMA/CA). The DCF shall be implemented in all STAs, for use within both IBSS 
and infrastructure network configurations. 

For a STA to transmit, it shall sense the medium to determine if another STA is transmitting. If the medium 
is not determined to be busy (see 9.2.1), the transmission may proceed. The CSMA/CA distributed algorithm 
mandates that a gap of a minimum specified duration exist between contiguous frame sequences. A transmit- 
ting STA shall ensure that the medium is idle for this required duration before attempting to transmit. If the 
medium is determined to be busy, the STA shall defer until the end of the current transmission. After defer- 
ral, or prior to attempting to transmit again immediately after a successful transmission, the STA shall select 
a random backoff interval and shall decrement the backoff interval counter while the medium is idle. A 
refinement of the method may be used under various circumstances to further minimize collisions — here the 
transmitting and .receiving .STA exchange short control frames [request to 'send (RTS) and clear to send 
(CTS) frames] after determining that the medium is idle and after any deferrals or backoffs, prior to data 
transmission. The details of CSMA/CA, deferrals, and backoffs are described in 9.2. RTS/CTS exchanges 
are also presented in 9.2. 



9.1.2 Point coordination function (PCF) 



The IEEE 802.1 1 MAC may also incorporate an optional access method called a PCF, which is only usable 
on infrastructure network configurations. This access method uses a point coordinator (PC), which shall 
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operate at the access point of the BSS, to determine which STA currently has the right to transmit. The oper- 
ation is essentially that of polling, with the PC performing the role of the polling master. The operation of the 
PCF may require additional coordination, not specified in this standard, to permit efficient operation in cases 
where multiple point-coordinated BSSs are operating on the same channel, in overlapping physical space. 

The PCF uses a virtual carrier-sense mechanism aided by an access priority mechanism. The PCF shall dis- 
tribute information within Beacon management frames to gain control of the medium by setting the network 
allocation vector (NAV) in STAs. In addition, all frame transmissions under the PCF may use an interframe 
space (IFS) that is smaller than the IFS for frames transmitted via the DCF. The use of a smaller IFS implies 
that point-coordinated traffic shall have priority access to the medium over STAs in overlapping BSSs oper- 
ating under the DCF access method. 

The access priority provided by a PCF may be utilized to create a contention-free (CF) access method. The 
PC controls the frame transmissions of the STAs so as to eliminate contention for a limited period of time. 

9.1.3 Coexistence of DCF and PCF 

The DCF and the PCF shall coexist in a manner that permits both to operate concurrently within the same 
BSS. When a PC is operating in a BSS, the two access methods alternate, with a contention -free period 
(CFP) followed by a contention period (CP). This is described in greater detail in 93. 

9.1.4 Fragmentation/defragmentation overview 

The process of partitioning a MAC service data unit (MSDU) or a MAC management protocol data unit 
(MMPDU) into smaller MAC level frames, MAC protocol data units (MPDUs), is called fragmentation. 
Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length to increase reliability, by 
increasing the probability of successful transmission of the MSDU or MMPDU in cases where channel char- 
acteristics limit reception reliability for longer frames. Fragmentation is accomplished at each immediate 
transmitter. The process of recombining MPDUs into a single MSDU or MMPDU is defined as defragmen- 
tation. Defragmentation is accomplished at each immediate recipient. 

Only MPDUs with a unicast receiver address shall be fragmented. Broadcast/multicast frames shall not be 
fragmented even if their length exceeds aFragmentationThreshoId. 

When a directed MSDU is received from the LLC or a directed MMPDU is received from the MAC sublayer 
management entity (ML ME) with a length greater than aFragmentationThreshold, the MSDU or MMPDU 
shall be fragmented. The MSDU or MMPDU is divided into MPDUs. Each fragment is a frame no larger 
than aFragmentationThreshold. It is possible that any fragment may be a frame smaller than aFragmenta- 
tionThreshold. An illustration of fragmentation is shown in Figure 48. 



MSDU 




Fragment 0 Fragment 1 Fragment 2 Fragment 3 



Figure 48 — Fragmentation 

The MPDUs resulting from the fragmentation of an MSDU or MMPDU are sent as independent transmis- 
sions, each of which is separately acknowledged. This permits transmission retries to occur per fragment, 
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rather than per MSDU or MMPDU. Unless interrupted due to medium occupancy limitations for a given 
PHY, the fragments of a single MSDU or MMPDU are sent as a burst during the CP, using a single invoca- 
tion of the DCF medium access procedure. The fragments of a single MSDU or MMPDU are sent during a 
CFP as individual frames obeying the rules of the PC medium access procedure. 

9.1 .5 MAC data service 

The MAC data service shall translate MAC service requests from LLC into input signals utilized by the 
MAC state machines. The MAC data service shall also translate output signals from the MAC state machines 
into service indications to LLC. The translations are given in the MAC data service state machine defined in 
Annex C. 

9.2 DCF 

The basic medium access protocol is a DCF that allows for automatic medium sharing between compatible 
PHYs through the use of CSMA/CA and a random backoff time following a busy medium condition. In 
addition, all directed traffic uses immediate positive acknowledgment (ACK frame) where retransmission is 
scheduled by the sender if no ACK is received. 

The CSMA/CA protocol is designed to reduce the collision probability between multiple STAs accessing a 
medium, at the point where collisions would most likely occur. Just after the medium becomes idle follow- 
ing a busy medium (as indicated by the CS function) is when the highest probability of a collision exists. 
This is because multiple STAs could have been waiting for the medium to become available again. This is 
the situation that necessitates a random backoff procedure to resolve medium contention conflicts. 

Carrier sense shall be performed both through physical and virtual mechanisms. 

The virtual carrier-sense mechanism is achieved by distributing reservation information announcing the 
impending use of the medium. The exchange of RTS and CTS frames prior to the actual data frame is one 
means of distribution of this medium reservation information. The RTS and CTS frames contain a Duration/ 
ID field that defines the period of time that the medium is to be reserved to transmit the actual data frame and 
the returning ACK frame. All STAs within the reception range of either the originating STA (which transmits 
the RTS) or the destination STA (which transmits the CTS) shall learn of the medium reservation. Thus a 
STA can be unable to receive from the originating STA, yet still know about the impending use of the 
medium to transmit a data frame. 

Another means of distributing the medium reservation information is the Duration/ID field in directed 
frames. This field gives the time that the medium is reserved, either to the end of the immediately following 
ACK, or in the case of a fragment sequence, to the end of the ACK following the next fragment. 

The RTS/CTS exchange also performs both a type of fast collision inference and a transmission path check. 
If the return CTS is not detected by the STA originating the RTS, the originating STA may repeat the process 
(after observing the other medium-use rules) more quickly than if the long data frame had been transmitted 
and a return ACK frame had not been detected. 

Another advantage of the RTS/CTS mechanism occurs where multiple BSSs utilizing the same channel 
overlap. The medium reservation mechanism works across the BSA boundaries. The RTS/CTS mechanism 
may also improve operation in a typical situation where all STAs can receive from the AP, but cannot receive 
from all other STAs in the BSA. 

The RTS/CTS mechanism cannot be used for MPDUs with broadcast and multicast immediate address 
because there are multiple destinations for the RTS, and thus potentially multiple concurrent senders of the 
CTS in response. The RTS/CTS mechanism need not be used for every data frame transmission. Because the 
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additional RTS and CTS frames add overhead inefficiency, the mechanism is not always justified, especially 
for short data frames. 

The use of the RTS/CTS mechanism is under control of the dot! 1 RTSThreshold attribute. This attribute may 
be set on a per-STA basis. This mechanism allows STAs to be configured to use RTS/CTS either always, 
never, or only on frames longer than a specified length. 

A STA configured not to initiate the RTS/CTS mechanism shall still update its virtual carrier-sense mecha- 
nism with the duration information contained in a received RTS or CTS frame, and shall always respond to 
an RTS addressed to it with a CTS. 

The medium access protocol allows for STAs to support different sets of data rates. All STAs shall receive all 
the data rates in a Basic Rate Set and transmit at one or more of the aBasicRateSet data rates. To support the 
proper operation of the RTS/CTS and the virtual carrier-sense mechanism, all STAs shall be able to detect 
the RTS and CTS frames. For this reason the RTS and CTS frames shall be transmitted at one of the aBasi- 
cRateSet rates. (See 9.6 for a description of multirate operation.) 

Data frames sent under the DCF shall use the frame type Data and subtype Data or Null Function. STAs 
receiving Data type frames shall only consider the frame body as the basis of a possible indication to LLC. 

9.2.1 Carrier-sense mechanism 

Physical and virtual carrier-sense functions are used to determine the state of the medium. When either func- 
tion indicates a busy medium, the medium shall be considered busy; otherwise, it shall be considered idle. 

A physical carrier-sense mechanism shall be provided by the PHY. See Clause 12 for how this information is 
conveyed to the MAC. The details of physical carrier sense are provided in the individual PHY specifica- 
tions. 

A virtual carrier- sense mechanism shall be provided by the MAC. This mechanism is referred to as the net- 
work allocation vector (NAV). The NAV maintains a prediction of future traffic on the medium based on 
duration information that is announced in RTS/CTS frames prior to the actual exchange of data. The dura- 
tion information is also available in the MAC headers of all frames sent during the CP other than PS- Poll 
Control frames. The mechanism for setting the NAV using RTS/CTS in the DCF is described in 9.2.5.4, and 
use of the NAV in PCF is described in 9.3.2.2. 

The carrier- sense mechanism combines the NAV state and the STA's transmitter status with physical carrier 
sense to determine the busy/idle state of the medium. The NAV may be thought of as a counter, which counts 
down to zero at a uniform rate. When the counter is zero, the virtual carrier-sense indication is that the 
medium is idle; when nonzero, the indication is busy. The medium shall be determined to be busy whenever 
the STA is transmitting. 

9.2.2 MAC-Level acknowledgments 

The reception of some frames, as described in 9.7, 9.2.8, and 9.3.3.4, requires the receiving STA to respond 
with an acknowledgment, generally an ACK frame, if the FCS of the received frame is correct. This tech- 
nique is known as positive acknowledgment. 

Lack of reception of an expected ACK frame indicates to the source STA that an error has occurred. Note, 
however, that the destination STA may have received the frame correctly, and that the error may have 
occurred in the reception of the ACK frame. To the initiator of the frame exchange, this condition is indistin- 
guishable from an error occurring in the initial frame. 
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9.2.3 Interframe space (IFS) 

The time interval between frames is called the IFS. A STA shall determine that the medium is idle through 
the use of the carrier-sense function for the interval specified. Four different IFSs are defined to provide pri- 
ority levels for access to the wireless media; they are listed in order, from the shortest to the longest. Figure 
49 shows some of these relationships. 

a) SIFS short interframe space 

b) PIFS PCF interframe space 

c) DIFS DCF interframe space 

d) EIFS extended interframe space 

The different IFSs shall be independent of the STA bit rate. The IFS timings shall be defined as time gaps on 
the medium, and shall be fixed for each PHY (even in multirate-capable PHYs). The IFS values are deter- 
mined from attributes specified by the PHY. 
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Figure 49— Some IFS relationships 



9.2.3.1 Short IFS (SIFS) 

The SIFS shall be used for an ACK. frame, a CTS frame, the second or subsequent MPDU of a fragment 
burst, and by a STA responding to any polling by the PCF. It may also be used by a PC for any types of 
frames during the CFP (see 9.3). The SIFS is the time from the end of the last symbol of the previous frame 
to the beginning of the first symbol of the preamble of the subsequent frame as seen at the air interface. The 
valid cases where the SIFS may or shall be used are listed in the frame exchange sequences in 9.7. 

The SIFS timing shall be achieved when the transmission of the subsequent frame is started at the TxSIFS 
Slot boundary as specified in 9.2.10. An IEEE 802.1 1 implementation shall not allow the space between 
frames that are defined to be separated by a SIFS time, as measured on the medium, to vary from the nomi- 
nal SIFS value by more than ±10% of aSIotTime for the PHY in use. 

SIFS is the shortest of the interframe spaces. SIFS shall be used when STAs have seized the medium and 
need to keep it for the duration of the frame exchange sequence to be performed. Using the smallest gap 
between transmissions within the frame exchange sequence prevents other STAs, which are required to wait 
for the medium to be idle fer a longer gap, from attempting to use the medium, thus giving priority to com- 
pletion of the frame exchange sequence in progress. 

9.2.3.2 PCF IFS (PIFS) 

The PIFS shall be used only by STAs operating under the PCF to gain priority access to the medium at the 
start of the CFP. A STA using the PCF shall be allowed to transmit contention -free traffic after its carrier* 
sense mechanism (see 9.2.1) determines that the medium is idle at the TxPIFS slot boundary as defined in 
9.2.10. Subclause 9.3 describes the use of the PIFS by STAs operating under the PCF. 
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9.2.3.3 DCF IFS (DIFS) 

The DIFS shall be used by STAs operating under the DCF to transmit data frames (MPDUs) and manage- 
ment frames (MMPDUs). A STA using the DCF shall be allowed to transmit if its carrier-sense mechanism 
(see 9.2. 1 ) determines that the medium is idle at the TxDIFS slot boundary as defined in 9.2.10 after a cor- 
rectly received frame, and its backoff time has expired. A STA using the DCF shall not transmit within an 
EIFS after it determines that the medium is idle following reception of a frame for which the PHYRX- 
END. indication primitive contained an error or a frame for which the MAC FCS value was not correct. A 
STA may transmit after subsequent reception of an error- free frame, resynchronizing the STA. This allows 
the STA to transmit using the DIFS following that frame. 

9.2.3.4 Extended IFS (EIFS) 

The EIFS shall be used by the DCF whenever the PHY has indicated to the MAC that a frame transmission 
was begun that did not result in the correct reception of a complete MAC frame with a correct FCS value. 
The duration of an EIFS is defined in 9.2. 10. The EIFS interval shall begin following indication by the PHY 
that the medium is idle after detection of the erroneous frame, without regard to the virtual carrier-sense 
mechanism. The EIFS is defined to provide enough time for another STA to acknowledge what was, to this 
STA, an incorrectly received frame before this STA commences transmission. Reception of an error-free 
frame during the EIFS resynchronizes the STA to the actual busy/idle state of the medium, so the EIFS is ter- 
minated and normal medium access (using DIFS and, if necessary, backoff) continues following reception of 
that frame. 

9.2.4 Random backoff time 

A STA desiring to initiate transfer of data MPDUs and/or management MMPDUs shall invoke the carrier-sense 
mechanism (see 9.2.1) to determine the busy/idle state of the medium. If the medium is busy, the STA shall 
defer until the medium is determined to be idle without interruption for a period of time equal to DIFS when 
the last frame detected on the medium was received correctly, or after the medium is determined to be idle 
without interruption for a period of time equal to EIFS when the last frame detected on the medium was not 
received correctly. After this DIFS or EIFS medium idle time, the STA shall then generate a random backoff 
period for an additional deferral time before transmitting, unless the backoff timer already contains a nonzero 
value, in which case the selection of a random number is not needed and not performed. This process mini- 
mizes collisions during contention between multiple STAs that have been deferring to the same event. 

Backoff Time = RandomQ x aSlotTime 

where 

Random() = Pseudorandom integer drawn from a uniform distribution over the interval [0,CW], where 
CW is an integer within the range of values of the PHY characteristics aCWmin and aCW- 
max, aCWmin < CW < aCWmax. It is important that designers recognize the need for 
statistical independence among the random number streams among STAs. 

aSlotTime = The value of the correspondingly named PHY characteristic. 

The contention window (CW) parameter shall take an initial value of aCWmin. Every STA shall maintain a 
STA short retry count (SSRC) as well as a STA long retry count (SLRC), both of which shall take an initial 
value of zero. The SSRC shall be incremented whenever any short retry count associated with any MSDU is 
incremented. The SLRC shall be incremented whenever any long retry count associated with any MSDU is 
incremented. The CW shall take the next value in the series every time an unsuccessful attempt to transmit an 
MPDU causes either STA retry counter to increment, until the CW reaches the value of aCWmax. A retry is 
defined as the entire sequence of frames sent, separated by SIFS intervals, in an attempt to deliver an MPDU, as 
described in 9.7. Once it reaches aCWmax, the CW shall remain at the value of aCWmax until it is reset. This 
improves the stability of the access protocol under high- load conditions. See Figure 50. 
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The CW shall be reset to aCWmin after every successful attempt to transmit an MSDU or MMPDU, when 
SLRC reaches aLongRetryLimit, or when SSRC reaches dot I IShortRetryLimit. The SSRC shall be reset to 
0 whenever a CTS frame is received in response to an RTS frame, whenever an ACK frame is received in 
response to an MPDU or MMPDU transmission, or whenever a frame with a group address in the Address 1 
field is transmitted. The SLRC shall be reset to 0 whenever an ACK frame is received in response to trans- 
mission of an MPDU or MMPDU of length greater than dotl I RTSThreshold, or whenever a frame with a 
group address in the Address! field is transmitted. 

The set of CW values shall be sequentially ascending integer powers of 2, minus I, beginning with a PHY- 
specific aCWmin value, and continuing up to and including a PHY-specific aCWmax value. 
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Figure 50 — An example of exponential increase of CW 



9.2.5 DCF access procedure 

The CSMA/CA access method is the foundation of the DCF. The operational rules vary slightly between the 
DCF and the PCF. 



9.2.5.1 Basic access 



Basic access refers to the core mechanism a STA uses to determine whether it may transmit. 

In general, a STA may transmit a pending MPDU when it is operating under the DCF access method, either 
in the absence of a PC, or in the CP of the PCF access method, when the STA determines that the medium is 
idle for greater than or equal to a DIFS period, or an EIFS period if the immediately preceding medium-busy 
event was caused by detection of a frame that was not received at this STA with a correct MAC FCS value. 
If, under these conditions* the. medium is determined by the carrier-sense mechanism to be busy when a STA 
desires to initiate the initial frame of one of the frame exchanges described in 9.7, exclusive of the CF 
period, the random backoff algorithm described in 9.2.5.2 shall be followed. There are conditions, specified 
in 9.2.5.2 and 9.2.5.5, where the random backoff algorithm shall be followed even for the first attempt to ini- 
tiate a frame exchange sequence. 

In a STA having an FH PHY, control of the channel is lost at the dwell time boundary and the STA shall have 
to contend for the channel after that dwell boundary. It is required that STAs having an FH PHY complete 
transmission of the entire MPDU and associated acknowledgment (if required) before the dwell time bound- 
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ary. If, when transmitting or retransmitting an MPDU, there is not enough time remaining in the dwell to 
allow transmission of the MPDU plus the acknowledgment (if required), the STA shall defer the transmis- 
sion by selecting a random backoff time, using the present CW (without advancing to the next value in the 
series). The short retry counter and long retry counter for the MSDU are not affected. 

The basic access mechanism is illustrated in Figure 5i. 
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Figure 51— Basic access method 



9.2.5.2 Backoff procedure 

The backoff procedure shall be invoked for a STA to transfer a frame when finding the medium busy as indi- 
cated by either the physical or virtual carrier-sense mechanism (see Figure 52). The backoff procedure shall 
also be invoked when a transmitting STA infers a failed transmission as defined in 9.2.5.7 or 9.2.8. 

To begin the backoff procedure, the STA shall set its Backoff Timer to a random backoff time using the equa- 
tion in 9.2.4. All backoff slots occur following a DIFS period during which the medium is determined to be idle 
for the duration of the DIFS period, or following an EIFS period during which the medium is determined to be 
idle for the duration of the EIFS period following detection of a frame that was not received correctly. 

A STA performing the backoff procedure shall use the carrier-sense mechanism (9.2. 1 ) to determine whether 
there is activity during each backorT slot. If no medium activity is indicated for the duration of a particular 
backoff slot, then the backoff procedure shall decrement its backoff time by aSlotTime. 

If the medium is determined to be busy at any time during a backoff slot, then the backoff procedure is sus- 
pended; that is, the backoff timer shall not decrement for that slot. The medium shall be determined to be 
idle for the duration of a DIFS period or EIFS, as appropriate (see 9.2.3), before the backoff procedure is 
allowed to resume. Transmission shall commence whenever the Backoff Timer reaches zero. 

A backorT procedure shall be performed immediately after the end of every transmission with the More Frag- 
ments bit set to 0 of an MPDU of type Data, Management, or Control with subtype PS-Poll, even if no addi- 
tional transmissions are currently queued. In the case of successful acknowledged transmissions, this backoff 
procedure shall begin at the end of the received ACFC frame. In the case of unsuccessful transmissions requiring 
acknowledgment, this backoff procedure shall begin at the end of the ACK timeout interval. If the transmission 
is successful, the CW value reverts to aCWmin before the random backoff interval is chosen, and the STA short 
retry count and/or STA long retry count are updated as described in 9.2.4. This assures that transmitted frames 
from a STA are always separated by at least one backoff interval. 

The effect of this procedure is that when multiple STAs are deferring and go into random backoff, then the 
STA selecting the smallest backoff time using the random function will win the contention. 
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Figure 52— Backoff procedure 



In an IBSS, the backoff time for a pending non-beacon or non-ATIM transmission shall not decrement in the 
period from the target beacon transmission time (TBTT) until the expiration of the ATIM window, and the 
backoff time for a pending ATIM management frame shall decrement only within the ATIM window. (See 
Clause 11.) Within an IBSS, a separate backoff interval shall be generated to precede the transmission of a 
beacon, as described in 1 1 . 1 .2.2. 

9.2.5.3 Recovery procedures and retransmit limits 

Error recovery is always the responsibility of the STA that initiates a frame exchange sequence, as defined in 
9.7. Many circumstances may cause an error to occur that requires recovery. For example, the CTS frame 
may not be returned after an RTS frame is transmitted. This may happen due to a collision with another 
transmission, due to interference in the channel during the RTS or CTS frame, or because the STA receiving 
the RTS frame has an active virtual carrier-sense condition (indicating a busy medium time period). 

Error recovery shall be attempted by retrying transmissions for frame exchange sequences that the initiating 
STA infers have failed. Retries shall continue, for each failing frame exchange sequence, until the transmis- 
sion is successful, or until the relevant retry limit is reached, whichever occurs first. STAs shall maintain a 
short retry count and a long retry count for each MSDU or MMPDU awaiting transmission. These counts are 
incremented and reset independently of each other. 

After an RTS frame is transmitted, the STA shall perform the CTS procedure, as defined in 9.2.5.7. If the 
RTS transmission fails, the short retry count for the MSDU or MMPDU and the STA short retry count are 
incremented. This process shall continue until the number of attempts to transmit that MSDU or MMPDU 
reaches dotl IShortRetry Limit. 

After transmitting a frame that requires acknowledgment, the STA shall perform the ACK procedure, as defined 
in 9.2.8. The short retry countfor an MSDU or MMPDU and the STA short retry count shall be incremented 
every time transmission of a MAC frame of length less than or equal to dotl IRTSThreshold fails for that 
MSDU or MMPDU. This short retry count and the STA short retry count shall be reset when a MAC frame of 
length less than or equal to dotl 1 RTSThreshold succeeds for that MSDU or MMPDU. The long retry count for 
an MSDU or MMPDU and the STA long retry count shall be incremented every time transmission of a MAC 
frame of length greater than dotl IRTSThreshold fails for that MSDU or MMPDU. This long retry count and 
the STA long retry count shall be reset when a MAC frame of length greater than dotl 1 RTSThreshold succeeds 
for that MSDU or MMPDU. All retransmission attempts for an MSDU or MMPDU that has failed the ACK 
procedure one or more times shall be made with the Retry field set to 1 in the Data or Management type frame. 
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Retries for failed transmission attempts shall continue until the short retry count for the MSDU or MMPDU is 
equal to dotl 1 ShortRetryLimit or until the long retry count for the MSDU or MMPDU is equal to 
aLongRetryLimit. When either of these limits is reached, retry attempts shall cease, and the MSDU or 
MMPDU shall be discarded. 



A STA in power-save mode, in an ESS, initiates a frame exchange sequence by transmitting a PS-Poll frame to 
request data from an AP. In the event that neither an ACK frame nor a data frame is received from the AP in 
response to a PS-Poll frame, then the STA shall retry the sequence, by transmitting another PS-Poll frame, at its 
convenience. If the AP sends a data frame in response to a PS-Poll frame, but fails to receive the ACK frame 
acknowledging this data frame, the next PS-Poll frame from the same STA may cause a retransmission of the 
last MSDU. This duplicate MSDU shall be filtered at the receiving STA using the normal duplicate frame filter- 
ing mechanism. If the AP responds to a PS-Poll by transmitting an ACK frame, then responsibility for the data 
frame delivery error recovery shifts to the AP because the data is transferred in a subsequent frame exchange 
sequence, which is initiated by the AP. The AP shall attempt to deliver one MSDU to the STA that transmitted 
the PS-Poll, using any frame exchange sequence valid for a directed MSDU. If the power save STA that trans- 
mitted the PS-Poll returns to Doze state after transmitting the ACK frame in response to successful receipt of 
this MSDU, but the AP fails to receive this ACK frame, the AP will retry transmission of this MSDU until the 
relevant retry limit is reached. See Clause 1 1 for details on filtering of extra PS-Poll frames. 

9.2.5.4 Setting and resetting the NAV 

STAs receiving a valid frame shall update their NAV with the information received in the Duration/ID field, 
but only when the new NAV value is greater than the current NAV value and only when the frame is not 
addressed to the receiving STA. Various additional conditions may set or reset the NAV, as described in 
93.2.2. When the NAV is reset, a PHY-CCARESETrequest shall be issued. 



Figure 53 indicates the NAV for STAs that may receive the RTS frame, while other STAs may only receive 
the CTS frame, resulting in the lower NAV bar as shown (with the exception of the STA to which the RTS 
was addressed). 
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Figure 53— RTS/CTS/data/ACK and NAV setting 



A STA that used information from an RTS frame as the most recent basis to update its NAV setting is permit- 
ted to reset its NAV if no PHY-RX START indication is detected from the PHY during a period with a dura- 
tion of (2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime) starting at the PHY-RXEND.indication 
corresponding to the detection of the RTS frame. The "CTS_Time" shall be calculated using the length of 
the CTS frame and the data rate at which the RTS frame used for the most recent NAV update was received. 



Copyright © 1999 IEEE. All rights reserved. 



79 



ISO/IEC 8802-11: 1999(E) 
ANSI/IEEE Std 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



9.2.5.5 Control of the channel 



The SIFS is used to provide an efficient MSDU delivery mechanism. Once the STA has contended for the 
channel, that STA shall continue to send fragments until either all fragments of a single MSDU or MMPDU 
have been sent, an acknowledgment is not received, or the STA is restricted from sending any additional 
fragments due to a dwell time boundary. Should the sending of the fragments be interrupted due to one of 
these reasons, when the next opportunity for transmission occurs the STA shall resume transmission. The 
algorithm by which the STA decides which of the outstanding MSDUs shall next be attempted after an 
unsuccessful transmission attempt is beyond the scope of this standard, but any such algorithm shall comply 
with the restrictions listed in 9.8. 

Figure 54 illustrates the transmission of a multiple-fragment MSDU using the SIFS. 
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Figure 54 — Transmission of a multiple-fragment MSDU using SIFS 



When the source STA transmits a fragment, it shall release the channel, then immediately monitor the chan- 
nel for an acknowledgment as described in 9.2.8. 

When the destination STA has finished sending the acknowledgment, the SIFS following the acknowledg- 
ment shall be reserved for the source STA to continue (if necessary) with another fragment. The STA send- 
ing the acknowledgment shall not transmit on the channel immediately following the acknowledgment. 

The process of sending multiple fragments after contending for the channel is defined as a fragment burst. 

If the source STA receives an acknowledgment but there is not enough time to transmit the next fragment 
and receive an acknowledgment due to an impending dwell boundary, the source STA shall contend for- the 
channel at the beginning of the next dwell time. 

If the source STA does not receive an acknowledgment frame, it shall attempt to retransmit the failed MPDU or 
another eligible MPDU, as defined in 9.8, after performing the backoff procedure and the contention process. 

After a STA contends for the channel to retransmit a fragment of an MSDU, it shall start with the last frag- 
ment that was not acknowledged. The destination STA shall receive the fragments in order (since the source 
sends them in order, and they are individually acknowledged). It is possible, however, that the destination 
STA may receive duplicate fragments. It shall be the responsibility of the receiving STA to detect and dis- 
card duplicate fragments. 

A STA shall transmit after the SIFS only under the following conditions during a fragment burst: 
— The STA has just received a fragment that requires acknowledgment. 
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— The source STA has received an ac know led gment for a previous fragment, has more fragment(s) for 
the same MSDU to transmit, and there is enough time before the next dwell boundary to send the 
next fragment and receive its acknowledgment. 

The following rules shall also apply: 

— When a STA has transmitted a frame other than an initial or intermediate fragment, that STA shall 
not transmit on the channel following the acknowledgment for that frame, without performing the 
backoff procedure. 

— When an MSDU has been successfully delivered or all retransmission attempts have been exhausted, 
and the STA has a subsequent MSDU to transmit, then that STA shall perform a backoff procedure. 

— Only unacknowledged fragments shall be retransmitted. 

9.2.5.6 RTS/CTS usage with fragmentation 

The following is a description of using RTS/CTS for a fragmented MSDU or MMPDU. The RTS/CTS 
frames define the duration of the following frame and acknowledgment. The Duration/ID field in the data 
and acknowledgment (ACK) frames specifies the total duration of the next fragment and acknowledgment. 
This is illustrated in Figure 55. 
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Figure 55 — RTS/CTS with fragmented MSDU 



Each frame contains information that defines the duration of the next transmission. The duration information 
from RTS frames shall be used to update the NAV to indicate busy until the end of ACK 0. The duration 
information from the CTS frame shall also be used to update the NAV to indicate busy until the end of 
ACK 0. Both Fragment 0 and ACK 0 shall contain duration information to update the NAV to indicate busy 
until the end of ACK 1. This shall be done by using the Duration/ID field in the Data and ACK frames. This 
shall continue until the last fragment, which shall have a duration of one ACK time plus one SIFS time, and 
its ACK, which shall have its Duration/ID field set to zero. Each fragment and ACK acts as a virtual RTS and 
CTS; therefore no further RTS/CTS frames need to be generated after the RTS/CTS that began the frame 
exchange sequence even though subsequent fragments may be larger than dotl IRTSThreshold. At STAs 
using a frequency-hopping PHY, when there is insufficient time before the next dwell boundary to transmit 
the subsequent fragment, the STA initiating the frame exchange sequence may set the Duration/ID field in 
the last data or management frame to be transmitted before the dwell boundary to the duration of one ACK 
time plus one SIFS time. 

In the case where an acknowledgment is sent but not received by the source STA, STAs that heard the frag- 
ment, or ACK, will mark the channel busy for the next frame exchange due to the NAV having been updated 
from these frames. This is the worst-case situation, and it is shown in Figure 56. If an acknowledgment is not 
sent by the destination STA, STAs that can only hear the destination STA will not update their NAV and may 
attempt to access the channel when their NAV updated from the previously received frame reaches zero. All 
STAs that hear the source will be free to access the channel after their NAV updated from the transmitted 
fragment has expired. 
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Figure 56 — RTS/CTS with transmitter priority and missed acknowledgment 
9.2.5.7 CTS procedure 

A STA that is addressed by an RTS frame shall transmit a CTS frame after a SIFS period if the NAV at the 
STA receiving the RTS frame indicates that the medium is idle. If the NAV at the STA receiving the RTS 
indicates the medium is not idle, that STA shall not respond to the RTS frame. The RA field of the CTS 
frame shall be the value obtained from the TA field of the RTS frame to which this CTS frame is a response. 
The Duration/ID field in the CTS frame shall be the duration field from the received RTS frame, adjusted by 
subtraction of aSIFSTime and the number of microseconds required to transmit a CTS frame at the data rate 
used for the RTS frame to which this CTS frame is a response. 

After transmitting an RTS frame, the STA shall wait for a CTSTimeout interval, starting at the PHY- 
TXEND.confirm. If a PHY-RXSTART.indication does not occur during the CTSTimeout interval, the STA 
shall conclude that the transmission of the RTS has failed, and this STA shall invoke its backoff procedure 
upon expiration of the CTSTimeout interval. If a PHY-RXSTART.indication does occur during the 
CTSTimeout interval, the STA shall wait for the corresponding PHY-RXEND. indication to determine 
whether the RTS transmission was successful. The recognition of a valid CTS frame sent by the recipient of 
the RTS frame, corresponding to this PHY-RXEND.indication, shall be interpreted as successful response, 
permitting the frame sequence to continue (see 9.7). The recognition of anything else, including any other 
valid frame, shall be interpreted as failure of the RTS transmission. In this instance, the STA shall invoke its 
backoff procedure at the PHY-RXEND. indication and may process the received frame. 

9.2.6 Directed MPDU transfer procedure 

A STA shall use an RTS/CTS exchange for directed frames only when the length of the MPDU is greater 
than the length threshold indicated by the dotl IRTSThreshold attribute. 

The dotl IRTSThreshold attribute shall be a managed object within the MAC MIB, and its value may be set 
and retrieved by the MAC LME. The value 0 shall be used to indicate that all MPDUs shall be delivered with 
the use of RTS/CTS. Values of dotl IRTSThreshold larger than the maximum MSDU length shall indicate 
that all MPDUs shall be delivered without RTS/CTS exchanges. 

When an RTS/CTS exchange is used, the asynchronous data frame shall be transmitted after the end of the 
CTS frame and a SIFS period. No regard shall be given to the busy or idle status of the medium when trans- 
mitting this data frame. 



82 



Copyright © 1999 IEEE. All rights reserved. 



ISO/IEC 8802-11: 1999(E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.1 1. 1999 Edition 



When an RTS/CTS exchange is not used, the asynchronous data frame shall be transmitted following the 
success of the basic access procedure. With or without the use of the RTS/CTS exchange procedure, the STA 
that is the destination of an asynchronous data frame shall follow the ACK procedure. 

9.2.7 Broadcast and multicast MPDU transfer procedure 

In the absence of a PCF, when broadcast or multicast MPDUs are transferred from a STA with the ToDS bit 
clear, only the basic access procedure shall be used. Regardless of the length of the frame, no RTS/CTS 
exchange shall be used. In addition, no ACK shall be transmitted by any of the recipients of the frame. Any 
broadcast or multicast MPDUs transferred from a STA with a ToDS bit set shall, in addition to conforming 
to the basic access procedure of CSMA/CA, obey the rules for RTS/CTS exchange, because the MPDU is 
directed to the AP. The broadcast/multicast message shall be distributed into the BSS. The STA originating 
the message shall receive the message as a broadcast/multicast message. Therefore, all STAs shall filter out 
broadcast/multicast messages that contain their address as the source address. Broadcast and multicast 
MSDUs shall be propagated throughout the ESS. 

There is no MAC-level recovery on broadcast or multicast frames, except for those frames sent with the ToDS 
bit set. As a result, the reliability of this traffic is reduced, relative to the reliability of directed traffic, due to the 
increased probability of lost frames from interference, collisions, or time- varying channel properties. 

9.2.8 ACK procedure 

An ACK frame shall be generated as shown in the frame exchange sequences listed in 9.7. 

Upon successful reception of a frame of a type that requires acknowledgment with the ToDS bit set, an AP 
shall generate an ACK frame. An ACK frame shall be transmitted by the destination STA that is not an AP, 
whenever it successfully receives a unicast frame of a type that requires acknowledgment, but not if it 
receives a broadcast or multicast frame of such type. After a successful reception of a frame requiring 
acknowledgment, transmission of the ACK frame shall commence after a SIFS period, without regard to the 
busy/idle state of the medium. 

The source STA shall wait ACKTimeout amount of time without receiving an ACK frame before concluding 
that the MPDU failed. (See Figure 57.) 

After transmitting an MPDU that requires an ACK frame as a response (see 9.7), the STA shall wait for an ACK- 
Timeout interval, starting at the PHY-TXEND.confirm. If a PHY- RXSTART. indication does not occur during 
the ACKTimeout interval, the STA concludes that the transmission of the MPDU has failed, and this STA shall 
invoke its backoff procedure upon expiration of the ACKTimeout interval. If a PHY-RXSTART.indication does 
occur during the ACKTimeout interval, the STA shall wait for the corresponding PHY-RXEND. indication to 
determine whether the MPDU transmission was successful. The recognition of a valid ACK frame sent by the 
recipient of the MPDU requiring acknowledgment, corresponding to this PHY-RXEND. indication, shall be 
interpreted as successful acknowledgment, permitting the frame sequence to continue, or to end without retries, 
as appropriate for the particular frame sequence in progress. The recognition of anything else, including any 
other valid frame, shall be interpreted as failure of the MPDU transmission. In this instance, the STA shall invoke 
its backoff procedure at the PHY-RXEND. indication and may process the received frame. The sole exception is 
that recognition of a valid data frame sent by the recipient of a PS- Poll frame shall also be accepted as successful 
acknowledgment of the PS- Poll frame. 

9.2.9 Duplicate detection and recovery 

Since MAC-level acknowledgments and retransmissions are incorporated into the protocol, there is the pos- 
sibility that a frame may be received more than once. Such duplicate frames shall be filtered out within the 
destination MAC. 
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Figure 57— Directed data/ACK MPDU 



Duplicate frame filtering is facilitated through the inclusion of a Sequence Control field (consisting of a 
sequence number and fragment number) within data and management frames. MPDUs that are part of the 
same MSDU shall have the same sequence number, and different MSDUs shall (with a high probability) 
have a different sequence number. 

The sequence number is generated by the transmitting STA as an incrementing sequence of integers. 

The receiving STA shall keep a cache of recently received <Address 2, sequence-number, fragment-num- 
bed tuples. A receiving STA is required to keep only the most recent cache entry per Address 2 -sequence- 
number pair, storing only the most recently received fragment number for that pair. A receiving STA may 
omit tuples obtained from broadcast/multicast or ATIM frames from the cache. 

A destination STA shall reject as a duplicate frame any frame that has the Retry bit set in the Frame Control 
field and that matches an <Address 2, sequence-number, and fragment-number> tuple of an entry in the cache. 

There is a small possibility that a frame may be improperly rejected due to such a match; however, this 
occurrence would be rare and simply results in a lost frame (similar to an FCS error in other LAN protocols). 

The destination STA shall perform the ACK procedure on all successfully received frames requiring 
acknowledgment, even if the frame is discarded due to duplicate filtering. 

9.2.10 DCF timing relations 

The relationships between the IFS specifications are defined as time gaps on the medium. The associated 
attributes are provided by the specific PHY. (See Figure 58.) 

All timings that are referenced from the end of the transmission are referenced from the end of the last sym- 
bol of a frame on the medium. The beginning of transmission refers to the first symbol of the next frame on 
the medium. 
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Figure 58 — DCF timing relationships 

aSIFSTime and aSlotTime are fixed per PHY. 

aSIFSTime is: aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + aRxTxTurnaroundTime. 

aSlotTime is: aCCATime + aRxTxTurnaroundTime + aAirPropagationTime 
+ aMACProcessingDelay. 

The PIFS and DIFS are derived by the following equations, as illustrated in Figure 58. 

PIFS = aSIFSTime + aSlotTime 

DIFS = aSIFSTime + 2x aSlotTime 

The EIFS is derived from the SIFS and the DIFS and the length of time it takes to transmit an ACK Control 
frame at 1 Mbit/s by the following equation: 

EIFS = aSIFSTime + (8 x ACKSize) + aPreambleLength + aPLCPHeaderLngth+ DIFS 

where 

ACKSize is the length, in bytes, of an ACK frame; and 

(8 x ACKSize)+ aPreambleLength + aPLCPHeaderLngth is expressed in microseconds required to trans- 
mit at the PHY's lowest mandatory rate. 

Figure 58 illustrates the relation between the SIFS, PIFS, and DIFS as they are measured on the medium and 
the different MAC slot boundaries TxSIFS, TxPIFS, and TxDIFS. These slot boundaries define when the 
transmitter shall be turned on by the MAC to meet the different IFS timings on the medium, after subsequent 
detection of the CCA result of the previous slot time. 



Copyright © 1999 IEEE. All rights reserved. 



85 



ISO/IEC 8802-11: 1999(E) 

ANSI/IEEE Std 802.11, 1999 Edition LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 

The following equations define the MAC Slot Boundaries, using attributes provided by the PHY, which are 
such that they compensate for implementation timing variations. The starting reference of these slot bound- 
aries is again the end of the last symbol of the previous frame on the medium. 

TxSIFS = SIFS - aRxTxTurnaroundTime 

TxPIFS = TxSIFS + aSlotTime 

TxDIFS = TxSIFS + 2 x aSlotTime. 

The tolerances are specified in the PLME SAP Interface Specification (1 0.4), and shall only apply to the 
SIFS specification, so that tolerances shall not accumulate. 

9.3 PCF 

The PCF provides contention-free frame transfer. The PC shall reside in the AP. It is an option for an AP to 
be able to become the PC. AH STAs inherently obey the medium access rules of the PCF, because these rules 
are based on the DCF, and they set their NAV at the beginning of each CFP. The operating characteristics of 
the PCF are such that all STAs are able to operate properly in the presence of a BSS in which a PC is operat- 
ing, and, if associated with a point-coordinated BSS, are able to receive all frames sent under PCF control. It 
is also an option for a STA to be able to respond to a contention -free poll (CF-Poll) received from a PC. A 
STA that is able to respond to CF-Polls is referred to as being CF-Pollable, and may request to be polled by 
an active PC. CF-Pollable STAs and the PC do not use RTS/CTS in the CFP. When polled by the PC, a CF- 
Pollable STA may transmit only one MPDU, which can be to any destination (not just to the PC), and may 
"piggyback" the acknowledgment of a frame received from the PC using particular data frame subtypes for 
this transmission. If the data frame is not in turn acknowledged, the CF-Pollable STA shall not retransmit the 
frame unless it is polled again by the PC, or it decides to retransmit during the CP. If the addressed recipient 
of a CF transmission is not CF-Pollable, that STA acknowledges the transmission using the DCF acknowl- 
edgment rules, and the PC retains control of the medium. A PC may use contention-free frame transfer 
solely for delivery of frames to STAs, and never to poll non-CF-Pollable STAs. 

A PC may perform a backoff on retransmission of an unacknowledged frame during the CFP. A PC that is 
maintaining a polling list may retry the unacknowledged frame the next time the particular AID is at the top 
of the polling list. 

A PC may retransmit an unacknowledged frame during the CFP after a PIFS time. 

When more than one point-coordinated BSS is operating on the same PHY channel in overlapping space, the 
potential exists for collisions between PCF transfer activities by the independent PCs. The rules under which 
multiple, overlapping point-coordinated BSSs may coexist are presented in 9.3.3.2. As shown in Figure 47, 
the PCF is built on top of the CSMA/CA-based DCF, by utilizing the access priority provisions provided by 
this scheme. An active PC shall be located at an AP, which restricts PCF operation to infrastructure net- 
works. PCF is activated at a PC-capable AP by setting the CFPMaxDuration parameter in the CF Parameter 
Set of the MLMEStart.request to a non-zero value. 

Data frames sent during under the DCF shall use the data subtypes Data or Null Function. Data frames sent 
by, or in response to polling by, the PC during the CFP shall use the appropriate data subtypes based upon 
the following usage rules: 

— Data+CF-Poll, Data+CF-Ack+CF-PolI, CF-Poll, and CF-Ack+CF-Poll shall only be sent by a PC. 

— Data, Data+CF-Ack, Null Function, and CF-Ack may be sent by a PC or by any CF-Pollable STA. 
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STAs receiving Data type frames shall only consider the frame body as the basis of a possible indication to 
LLC, if the frame is of subtype Data, Data+CF-Ack, Data+CF-Poll, or Data+CF-Ack+CF-Poll. CF-Pollable 
STAs shall interpret all subtype bits of received Data type frames for CF purposes, but shall only inspect the 
frame body if the frame is of subtype Data, Data+CF-Ack, Data+CF-Poll, or Data+CF-Ack+CF-Poil. 

9.3.1 CFP structure and timing 

The PCF controls frame transfers during a CFP. The CFP shall alternate with a CP, when the DCF controls 
frame transfers, as shown in Figure 59. Each CFP shall begin with a Beacon frame that contains a DTIM ele- 
ment (hereafter referred to as a "DTIM"). The CFPs shall occur at a defined repetition rate, which shall be 
synchronized with the beacon interval as specified in the following paragraphs. 

The PC generates CFPs at the contention-free repetition rate (CFPRate), which is defined as a number of 
DTIM intervals. The PC shall determine the CFPRate (depicted as a repetition interval in the illustrations in 
Figure 59 and Figure 60) to use from the CFPRate parameter in the CF Parameter Set. This value, in units of 
DTIM intervals, shall be communicated to other STAs in the BSS in the CFPPeriod field of the CF Parame- 
ter Set element of Beacon frames. The CF Parameter Set element shall only be present in Beacon and Probe 
Response frames transmitted by STAs containing an active PC. 
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Figure 59— CFP/CP alternation 
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Figure 60 — Beacons and CFPs 



The length of the CFP is controlled by the PC, with maximum duration specified by the value of the CFP- 
MaxDuration Parameter in the CF Parameter Set at the PC. Neither the maximum duration nor the actual 
duration (signaled by transmission of a Control frame of subtype CF-End or CF-End+ACK by the PC) is 
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constrained to be a multiple of the beacon interval. If the CFP duration is greater than the beacon interval, 
the PC shall transmit beacons at the appropriate times during the CFP (subject to delay due to traffic at the 
nominal times, as with all beacons). The CF Parameter Set element in all beacons at the start of, or within, a 
CFP shall contain a nonzero value in the CFPDurRemaining field. This value, in units of TU, shall specify 
the maximum time from the transmission of this beacon to the end of this CFP. The value of the CFPDurRe- 
maining field shall be zero in beacons sent during the CP. An example of these relationships is illustrated in 
Figure 60, which shows a case where the CFP is two DTIM intervals, the DTIM interval is three beacon 
intervals, and the aCFPMaxDuration value is approximately 2.5 beacon intervals. 

The PC may terminate any CFP at or before the aCFPMaxDuration, based on available traffic and size of the 
polling list. Because the transmission of any beacon may be delayed due to a medium busy condition at the 
nominal beacon transmission time, a CFP may be foreshortened by the amount of the delay. In the case of a 
busy medium due to DCF traffic, the beacon shall be delayed for the time required to complete the current 
DCF frame exchange. In cases where the beacon transmission is delayed, the CFPDurRemaining value in 
the beacon at the beginning of the CFP shall specify a time that causes the CFP to end no later than TBTT 
plus the value of aCFPMaxDuration. This is illustrated in Figure 61. 
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Figure 61— Example of delayed beacon and foreshortened CFP 



9.3.2 PCF access procedure 

The contention- free transfer protocol is based on a polling scheme controlled by a PC operating at the AP of 
the BSS. The PC gains control of the medium at the beginning of the CFP and attempts to maintain control 
for the entire CFP by waiting a shorter time between transmissions than the STAs using the DCF access pro- 
cedure. All STAs in the BSS (other than the PC) set their NAVs to the CFPMaxDuration value at the nominal 
start time of each CFP. This prevents most contention by preventing non-polled transmissions by STAs 
whether or not they are CF-Pollable. Acknowledgment of frames sent during the CFP may be accomplished 
using Data+CF-ACK, CF-ACK, Data+CF-ACK+CF-Poll (only on frames transmitted by the PC), or CF- 
ACK+CF-Poll (only on frames transmitted by the PC) frames in cases where a Data (or Null) frame immedi- 
ately follows the frame being acknowledged, thereby avoiding the overhead of separate ACK Control 
frames. Non-CF-Po liable or unpolled CF-Pollable STAs acknowledge frames during the CFP using the DCF 
ACK procedure. 

9.3.2.1 Fundamental access 

At the nominal beginning of each CFP, the PC shall sense the medium. When the medium is determined to 
be idle for one PIFS period, the PC shall transmit a Beacon frame containing the CF Parameter Set element 
and a DTIM element. 

After the initial beacon frame, the PC shall wait for at least one SIFS period, and then transmit one of the 
following: a data frame, a CF-Poll frame, a Data+CF-Poll frame, or a CF-End frame. If the CFP is null, i.e., 
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there is no traffic buffered and no polls to send at the PC, a CF-End frame shall be transmitted immediately 
after the initial beacon. 

STAs receiving directed, error-free frames from the PC are expected to respond after a SIFS period, in accor- 
dance with the transfer procedures defined in 9.3.3. If the recipient STA is not CF-Pollable, the response to 
receipt of an error-free data frame shall always be an ACK frame. 

9.3.2.2 NAV operation during the CFP 

The mechanism for handling the NAV during the CFP is designed to facilitate the operation of overlapping 
CFP coordinated infrastructure BSSs. The mechanism by which infrastructure BSSs coordinate their CFPs 
is beyond the scope of this standard. 

Each STA, except the STA with the PC, shall preset its NAV to the CFPMaxDuration value (obtained from 
the CF Parameter Set element in beacons from this PC) at each target beacon transmission time (TBTT) (see 
Clause 1 1) at which a CFP is scheduled to start (based on the CFPPeriod field in the CF Parameter Set 
element of the Beacon frames from this PC). Each non-PC STA shall update its NAV using the CFPDurRe- 
maining value in any error-free CF Parameter Set element of the Beacon frame that the STA receives. This 
includes CFPDurRemaining values in CF Parameter Set elements from Beacon frames received from other 
(overlapping) BSSs. 

These actions prevent STAs from taking control of the medium during the CFP, which is especially impor- 
tant in cases where the CFP spans multiple medium-occupancy intervals, such as dwell periods of an FH 
PHY. This setting of the NAV also reduces the risk of hidden STAs determining the medium to be idle for a 
DIFS period during the CFP and possibly corrupting a transmission in progress. 

A STA joining a BSS operating with a PC shall use the information in the CFPDurRemaining element of the 
CF parameter set of any received Beacon or Probe Response frames to update its NAV prior to initiating any 
transmissions. 

The PC shall transmit a CF-End or CF-End+ACK frame at the end of each CFP. A STA that receives either 
of these frames, from any BSS, shall reset its NAV. 

9.3.3 PCF transfer procedure 

Frame transfers under the PCF typically consist of frames alternately sent from the AP/PC and sent to the 
AP/PC. During the CFP, the ordering of these transmissions, and the STA allowed to transmit frames to the 
PC at any given point in time, shall be controlled by the PC. Figure 62 depicts a frame transfer during a typ- 
ical CFP. The rules under which this frame transfer takes place are detailed in the following subclauses. 

In a STA having an FH PHY, control of the channel is lost at a dwell time boundary. It is required that the 
current MPDU transmission and the accompanying acknowledgment of the MPDU be transmitted before the 
dwell time boundary. After having been polled by the PC, if there is not enough time remaining in the dwell 
to allow transmission of the MPDU plus the acknowledgment, the STA shall defer the transmission of the 
MPDU and shall transmit a Null frame or CF-ACK frame. The short retry counter and long retry counter for 
the MSDU shall not be affected. 

MaxMPDUTime is the time to transmit the maximum-sized MAC frame, expanded by WEP, plus the time to 
transmit the PHY preamble, header, trailer, and expansion bits, if any. In a STA having an FH PHY, the PC 
shall not transmit a CF-Poll to a STA if there is insufficient time remaining before the dwell boundary for the 
STA to respond with a Null frame or CF-ACK frame. 
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Figure 62 — Example of PCF frame transfer 



9.3.3.1 PCF transfers when the PCF STA is transmitter or recipient 

The PC shall transmit frames between the Beacon that starts the CFP and the CF-End using the SIFS except 
in cases where a transmission by another STA is expected by the PC and a SIFS period elapses without the 
receipt of the expected transmission. In such cases the PC may send its next pending transmission as soon as 
one PIFS after the end of its last transmission. This permits the PC to retain control of the medium in the 
presence of an overlapping BSS. The PC may transmit any of the following frame types to CF-Poilable 
STAs: 

— Data, used to send data from the PC when the addressed recipient is not being polled and there is no 
previous frame to acknowledge; 

— Data+CF-ACK, used to send data from the PC when the addressed recipient is not being polled and 
the PC needs to acknowledge the receipt of a frame received from a CF-Pollable STA a SIFS period 
before starting this transmission; 

— Data+CF-Poll, used to send data from the PC when the addressed recipient is the next STA to be per- 
mitted to transmit during this CFP and there is no previous frame to acknowledge; 

— Data+CF-ACK+CF-Poll, used to send data from the PC when the addressed recipient is the next STA 
to be permitted to transmit during this CFP and the PC needs to acknowledge the receipt of a frame 
received from a CF-Pollable STA a SIFS period before starting this transmission; 

— CF-Poll, used when the PC is not sending data to the addressed recipient, but the addressed recipient 
is the next STA to be permitted to transmit during this CFP and there is no previous frame to 
acknowledge; 

— CF-ACK+CF-Poll, used when the PC is not sending data to the addressed recipient but the addressed 
recipient is the next STA to be permitted to transmit during this CFP and the PC needs to acknowledge 
the receipt of a frame from a CF-Pollable STA a SIFS period before starting this transmission; 

— CF-ACK, used when the PC is not sending data to, or polling, the addressed recipient, but the PC 
needs to acknowledge receipt of a frame from a CF-Pollable STA a SIFS period before starting this 
transmission (useful when the next transmission by the PC is a management frame, such as a bea- 
con); or 

— Any management frame that is appropriate for the A P to send under the rules for that frame type. 

The PC may transmit data or management frames to non-CF-Pollable, non-power-save STAs during the 
CFP. These STAs shall acknowledge receipt with ACK frames after a SIFS, as with the DCF. The PC may 
also transmit broadcast or multicast frames during the CFP. Because the Beacon frame that initiates the CFP 
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contains a DTIM element, if there are associated STAs using power-save mode, the broadcasts and multi- 
casts buffered shall be sent immediately after any beacon containing a TIM element with a DTIM count field 
with a value of 0. 

A CF-Pollable STA that receives a directed data frame of any subtype that includes CF-Poll may transmit 
one data frame a SIFS period after receiving the CF-Poll. CF-Pollable STAs shall ignore, but not reset, their 
NAV when performing transmissions in response to a CF-Poll. 

Non-CF-Pollable STAs that receive a directed frame during the CFP shall transmit an ACFC, but shall not 
reset their NAV. 

For frames that require MAC-level acknowledgment, CF-Pollable STAs that received a CF-Poll (of any 
type) may perform this acknowledgment using the Data+CF-ACK subtype in the response to the CF-PolL 
For example, the Ul frame in Figure 62 contains the acknowledgment to the preceding Dl frame. The D2 
frame contains the acknowledgment to the preceding Ul frame. The PC may use the CF-ACK subtypes to 
acknowledge a received frame even if the data frame sent with the CF-ACK. subtype is addressed to a differ- 
ent STA than the one being acknowledged. CF-Pollable STAs that are expecting an acknowledgment shall 
interpret the subtype of the frame (if any) sent by the PC a SIFS period after that STA's transmission to the 
PC. If a frame that requires MAC-level acknowledgment is received by a non-CF-Pollable STA, that STA 
shall not interpret the CF-Poll indication (if any), and shall acknowledge the frame by sending an ACK Con- 
trol frame after a SIFS period. 

The lengths of the frames may be variable, only bounded by the frame and/or fragment length limitations that 
apply for the BSS. If a CF-Pollable STA does not respond to a CF-Poll (of any type) within the SIFS period fol- 
lowing a transmission from the PC, or a non-CF-Pollable STA does not return the ACK frame within a SIFS, 
period following a transmission from the PC that requires acknowledgment, then the PC shall resume control 
and may transmit its next frame after a PIFS period from the end of the PC's last transmission. 

A CF-Pollable STA shall always respond to a CF-Poll directed to its MAC address and received without 
error. If the STA has no frame to send when polled, the response shall be a Null frame. If the STA has no 
frame to send when polled, but an acknowledgment is required for the frame that conveyed the CF-Poll, the 
response shall be a CF-ACK (no data) frame. The null response is required to permit a "no-traffic" situation 
to be distinguished from a collision between overlapping PCs, 

The CFP shall end when the CFPDurRemaining time has elapsed since the Beacon frame originating the 
CFP or when the PC has no further frames to transmit nor STAs to poll. In either case, the end of the CFP 
shall be signaled by the transmission of a CF-End by the PC. If there is a received frame that requires 
acknowledgment at the time the CF-End is to be transmitted, the PC shall transmit a CF-End+ACK frame 
instead. All STAs of the BSS receiving a CF-End or CF-End+ACK shall reset their NAVs so they may 
attempt to transmit during the CP. 

9.3.3.2 Operation with overlapping point-coordinated BSSs 

Because the PCF operates without the CSMA/CA contention window randomization and backoff of the 
DCF, there is a risk of repeated collisions if multiple, overlapping, point-coordinated BSSs are operating on 
the same PHY channel, andtheir CFP Rates and beacon intervals are approximately equal. To minimize the 
risk of significant frame loss due to CF collisions, the PC shall use a DIFS plus a random backoff delay (with 
CW in the range of 1 to aCWrnin) to start a CFP when the initial beacon is delayed because of deferral due 
to a busy medium. The PC may optionally use this backoff during the CFP prior to retransmitting an unac- 
knowledged, directed data or management frame. 

To further reduce the susceptibility to inter- PC collisions, the PC shall require that the medium be deter- 
mined as being idle for a DIFS period plus a random (over a range of 1 to aCWrnin) number of slot times 
once every aMediumOccupancyLimit TU during the CFP. This results in loss of control of the medium to 
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overlapping BSS or hidden STA traffic, because the STAs in this BSS are prevented from transmitting by 
their NAV setting to CFPMaxDuration or CFPDurRemaining. For operation of the PCF in conjunction with 
an FH PHY, aMediumOccupancy Limit shall be set equal to the dwell time. For operation in conjunction 
with other PHY types, aMediumOccupancyLimit may be set equal to CFPMaxDuration, unless extra protec- 
tion against PCF collisions is desired. The aMediumOccupancyLimit is also useful for compliance in regula- 
tory domains that impose limits on continuous transmission time by a single STA as part of a spectrum 
etiquette. 

9.3.3.3 CFPMaxDuration limit 

The value of CFPMaxDuration shall be limited to allow coexistence between contention and contention- free 
traffic. 

The minimum value for CFPMaxDuration is two times MaxMPDUTime plus the time required to send the 
initial Beacon frame and the CF-End frame of the CFP. This may allow sufficient time for the AP to send one 
data frame to a STA, while polling that STA, and for the polled STA to respond with one data frame. 

The maximum value for CFPMaxDuration is the duration of (BeaconPeriod x DTIMPeriod x CFPRate) minus 
[MaxMPDUTime plus (2 x aSIFSTime) plus (2 x aSlotTime) plus (8 x ACKSize)], expressed in microseconds, 
when operating with a contention window of aCWmin. MaxMPDUTime is the time to transmit the maximum- 
sized MAC frame, expanded by WEP, plus the time to transmit the PHY preamble, header, trailer, and expansion 
bits, if any. This allows sufficient time to send at least one data frame during the CP. 

9.3.3.4 Contention-Free usage rules 

A PC may send broadcast or multicast frames, and directed data or management frames to any active STA, 
as well as to CF-Pollable power save STAs. During the CFP, CF-Pollable STAs shall acknowledge after a 
SIFS period, the receipt of each Data+CF-Poll frame or Data+CF-ACK+CF-Poll frame using Data+CF-Ack 
or CF-Ack (no data) frames, the receipt of each CF_Poll (no data) using Data or Null (no data), and the 
receipt of all other data and management frames using ACK Control frames. Non-CF-Pollable STAs shall 
acknowledge receipt of data and management frames using ACK Control frames sent after a SIFS period. 
This non-CF-Pollable operation is the same as that already employed by such STAs for DCF operation. 

When polled by the PCF ( Data+CF-Poll, Data+CF-ACK+CF-Poll, CF-Poll, or CF-ACK+CF-Poll) a CF- 
Pollable STA may send one data frame to any destination. Such a frame directed to or through the PC STA 
shall be acknowledged by the PC, using the CF-ACK indication (Data+CF-ACK, Data+CF-ACK+CF-Poll, 
CF-ACK, CF-ACK+CF-Poll, or CF-End+ACK) sent after a SIFS. Such a frame directed to a non-CF-Pol- 
lable STA shall be acknowledged using an ACK Control frame sent after a SIFS period. A polled CF-Pol- 
lable STA with neither .a data frame nor an acknowledgment to send shall respond by transmitting a Null 
frame after a SIFS period. A polled CF-Pollable STA with insufficient time before the end of the CFP or cur- 
rent medium occupancy limit, to send its queued MPDU and receive an acknowledgment, shall respond by 
transmitting a Null frame, or a CF-ACK frame if polled using Data+CF-Poll or Data+CF-ACK+CF-Poll, 
after a SIFS period. The CF-Pollable STA may set the More Data bit in its response to permit the PC to dis- 
tinguish between an empty STA queue and a response due to insufficient time to transfer an MPDU. 

The PC shall not issue frames, with a subtype that includes CF-Polls if insufficient time remains in the cur- 
rent CFP to permit the polled STA to transmit a data frame containing a minimum length MPDU. 

9.3.4 Contention-Free polling list 

If the PC supports use of the CFP for inbound frame transfer as well as for frame delivery, the PC shall main- 
tain a "polling list" for use in selecting STAs that are eligible to receive CF-Polls during CFPs. The polling 
list functional characteristics are defined below. If the PC supports the use of the CFP solely for frame deliv- 
ery, the PC does not require a polling list, and shall never generate data frames with a subtype that includes 
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CF-Poll. The form of contention- free support provided by the PC is identified in the Capability Information 
field of Beacon, Association Response, Reassociation Response, and Probe Response management frames, 
which are sent from APs. Any such frames sent by STAs, as in noninfrastructure networks, shall always have 
these bits set to zero. 

The polling list is used to force the polling of CF-Pollable STAs, whether or not the PC has pending traffic to 
transmit to those STAs. The polling list may be used to control the use of Data+CF-Poll and Data+CF- 
ACK+CF-Poll types for transmission of data frames being sent to CF-Pollable STAs by the PC. The polling 
list is a logical construct, which is not exposed outside of the PC. A minimum set of polling list maintenance 
techniques are required to ensure interoperability of arbitrary CF-Pollable STAs in BSSs controlled by arbi- 
trary access points with active PCs. APs may also implement additional polling list maintenance techniques 
that are outside the scope of this standard. 

9.3.4.1 Polling list processing 

The PC shall send a CF-Poll to at least one STA during each CFP when there are entries in the polling list. 
During each CFP, the PC shall issue polls to a subset of the STAs on the polling list in order by ascending 
AID value. 

While time remains in the CFP, all CF frames have been delivered, and all STAs on the polling list have been 
polled, the PC may generate one or more CF-Polls to any STAs on the polling list. While time remains in the 
CFP, all CF frames have been delievred, and all STAs on the polling list have been polled, the PC may send 
data or management frames to any STAs. 

In order to gain maximum efficiency from the CFP, and the ability to piggyback acknowledgments on suc- 
cessor data frames in the opposite direction, the PC should generally use Data+CF-Poll and Data+CF- 
ACK+CF-Poll types for each data frame transmitted while sufficient time for the potential response to the 
CF-Poll remains in the CFP. 

9.3.4.2 Polling list update procedure 

A STA indicates its CF-Po liability using the CF-Pollable subfield of the Capability Information field of 
Association Request and Reassociation Request frames. If a STA desires to change the PCs record of CF- 
Pollability, that STA shall perform a reassociation. During association, a CF-Poliable STA may also request 
to be placed on the polling list for the duration of its association, or by setting the CF-Poll Request subfield 
in the Capability Information field. If a CF-Pollable STA desires never to be placed on the polling list, that 
STA shall perform Association with both the CF-Pollable subfield false and the CF-Poll Request subfield 
true. Never being polled is useful for CF-Pollable STAs that normally use power-save mode, permitting 
them to receive buffered traffic during the CFP (since they have to be awake to receive the DTIM that initi- 
ated the CFP), but not requiring them to stay awake to receive CF-Polls when they have no traffic to send. If 
a STA desires to be removed from the polling list, that STA shall perform a reassociation. 

CF-Pollable STAs that are not on the polling list, but did not request never to be polled during their most 
recent association, may be dynamically placed on the polling list by the PC to handle bursts of frame transfer 
activity by that STA. 

9.4 Fragmentation 

The MAC may fragment and reassemble directed MSDUs or MMPDUs. The fragmentation and de fragmen- 
tation mechanisms allow for fragment retransmission. 

The length of a fragment MPDU shall be an equal number of octets for all fragments except the last, which 
may be smaller. The length of a fragment MPDU shall always be an even number of octets, except for the 
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last fragment of an MSDU or MMPDU, which may be either an even or an odd number of octets. The length 
of a fragment shall never be larger than aFragmentationThreshold unless WEP is invoked for the MPDIX If 
WEP is active for the MPDU, then the MPDU shall be expanded by IV and ICV (see 8.2.5); this may result 
in a fragment larger than aFragmentationThreshold. 

When data is to be transmitted, the number of octets in the fragment (before WEP processing) shall be deter- 
mined by aFragmentationThreshold and the number of octets in the MPDU that have yet to be assigned to a 
fragment at the instant the fragment is constructed for the first time. Once a fragment is transmitted for the 
first time, its frame body content and length shall be fixed until it is successfully delivered to the immediate 
receiving STA. A STA shall be capable of receiving fragments of arbitrary length. 

If a fragment requires retransmission, its frame body content and length shall remain fixed for the lifetime of 
the MSDU or MMPDU at that STA. After a fragment is transmitted once, contents and length of that frag- 
ment are not allowed to fluctuate to accommodate the dwell time boundaries. Each fragment shall contain"a 
Sequence Control field, which is comprised of a sequence number and fragment number. When a STA is 
transmitting an MSDU or MMPDU, the sequence number shall remain the same for all fragments of that 
MSDU or MMPDU. The fragments shall be sent in order of lowest fragment number to highest fragment 
number, where the fragment number value starts at zero, and increases by one for each successive fragment. 
The Frame Control field also contains a bit, the More Fragments bit, that is equal to zero to indicate the last 
(or only) fragment of the MSDU or MMPDU. 

The source STA shall maintain a transmit MSDU timer for each MSDU being transmitted. The attribute 
aMaxTransmitMSDULifetime specifies the maximum amount of time allowed to transmit an MSDU. The 
timer starts on the attempt to transmit the first fragment of the MSDU. If the timer exceeds aMaxTransmit- 
MSDULifetime, then all remaining fragments are discarded by the source STA and no attempt is made to 
complete transmission of the MSDU. 

9.5 Defragmentation 

Each fragment contains information to allow the complete MSDU or MMPDU to be reassembled from its 
constituent fragments. The header of each fragment contains the following information that is used by the 
destination STA to reassemble the MSDU or MMPDU: 

— Frame type 

— Address of the sender, obtained from the Address2 field 

— Destination address 

— Sequence Control field: This field allows the destination STA to check that all incoming fragments 
belong to the same MSDU or MMPDU, and the sequence in which the fragments should be reas- 
sembled. The sequence number within the Sequence Control field remains the same for all frag- 
ments of an MSDU or MMPDU, while the fragment number within the Sequence Control field 
increments for each fragment. 

— More Fragments indicator: Indicates to the destination STA that this is not the last fragment of the 
MSDU or MMPDU. Only the last or sole fragment of the MSDU or MMPDU shall have this bit set 
to zero. All other fragments of the MSDU or MMPDU shall have this bit set to one. 

The destination STA shall reconstruct the MSDU or MMPDU by combining the fragments in order of frag- 
ment number subfield of the Sequence Control field. If WEP has been applied to the fragment, it shall be 
decrypted before the fragment is used for defragmentation of the MSDU or MMPDU. If the fragment with 
the More Fragments bit set to zero has not yet been received, then the destination STA knows that the MSDU 
or MMPDU is not yet complete. As soon as the STA receives the fragment with the More Fragments bit set 
to zero, the STA knows that no more fragments may be received for the MSDU or MMPDU. 
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All STAs shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. Note 
that a STA receiving more than three fragmented MSDUs or MMPDUs concurrently may experience a sig- 
nificant increase in the number of frames discarded. 

The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received, for a min- 
imum of three MSDUs or MMPDUs. The STA may implement additional timers to be able to receive addi- 
tional concurrent MSDUs or MMPDUs. The receiving STA shall discard all fragments that are part of an 
MSDU or MMPDU for which a timer is not maintained. There is also an attribute, aMaxReceiveLifetime, 
that specifies the maximum amount of time allowed to receive an MSDU. The receive MSDU or MMPDU 
timer starts on the reception of the first fragment of the MSDU or MMPDU. If the receive MSDU timer 
exceeds aMaxReceiveLifetime, then all received fragments of this MSDU or MMPDU are discarded by the 
destination STA. If additional fragments of a directed MSDU or MMPDU are received after its aMaxRe- 
ceiveLifetime is exceeded, those fragments shall be acknowledged and discarded. 

To properly reassemble MPDUs into an, MSDU or MMPDU, a destination STA shall discard any duplicated 
fragments received. A STA shall discard duplicate fragments as described in 9.2.9. However, an acknowl- 
edgment shall be sent in response to a duplicate fragment of a directed MSDU. 

9.6 Mult irate support 

Some PHYs have multiple data transfer rate capabilities that allow implementations to perform dynamic rate 
switching with the objective of improving performance. The algorithm for performing rate switching is 
beyond the scope of this standard, but in order to ensure coexistence and interoperability on multirate-capa- 
ble PHYs, this standard defines a set of rules that shall be followed by all STAs. 

All Control frames shall be transmitted at one of the rates in the BSSBasicRateSet (see 10.3.10.1), or at one 
of the rates in the PHY mandatory rate set so they will be understood by all STAs. 

All frames with multicast and broadcast RA shall be transmitted at one of the rates included in the 
BSSBasicRateSet, regardless of their type. 

Data and/or management MPDUs with a unicast immediate address shall be sent on any supported data rate 
selected by the rate switching mechanism (whose output is an internal MAC variable called MACCurrentRate, 
defined in units of 500 kbit/s, which is used for calculating the Duration/ID field of each frame). A STA shall 
not transmit at a rate that is known not to be supported by the destination STA, as reported in the supported 
rates element in the management frames. For frames of type Data+CF- ACK, Data+CF-Poll+CF-ACK, and CF- 
PolI+CF-ACK, the rate chosen to transmit the frame must be supported by both the addressed recipient STA 
and the STA to which the ACK is intended. 

Under no circumstances shall a STA initiate transmission of a data or management frame at a data rate 
higher than the greatest rate in the Operational RateSet, a parameter of the MLME-JOIN.request primitive. 

In order to allow the transmitting STA to calculate the contents of the Duration/ID field, the responding STA 
shall transmit its Control Response frame (either CTS or ACK) at the same rate as the immediately previous 
frame in the frame exchange sequence (as defined in 9.7), if this rate belongs to the PHY mandatory rates, or 
else at the highest possible rate belonging to the PHY rates in the BSSBasicRateSet. 

9.7 Frame exchange sequences 

The allowable frame exchange sequences are summarized in Table 2! and Table 22. A legend applicable to 
both tables follows Table 22. 



Copyright© 1999 IEEE. All rights reserved. 



95 



ISO/IEC 8802-11: 1999(E) 
ANSI/IEEE Std 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



Table 21 — Frame sequences 



Sequence 


Frames in 
sequence 


Usage 


Data(bc/mc) 


I 


Broadcast or multicast MSDU 


Mgmt(bc) 


I 


Broadcast MMPDU 


{ RTS - CTS -} [Frag - ACK -] Last - ACK 


2 


Directed MSDU or MMPDU 


PS-Poll -ACK 


2 


Deferred PS-POLL response 


PS-Poll - [Frag - ACtC -] Last - ACK 


3 


Immediate PS-POLL response 


DTIM(CF) - [<CF-Sequence> -] {CF-End} 


2 or more 


Start of CFP 


[<CF-Sequence>-] {CF-End} 


2 or more 


Continuation of CFP after missing ACK or 
medium occupancy boundary 


Table 22 — CF frame sequences 


CF frame sequence 


Frames in 
sequence 


Usage 


Beacon(CF) 


1 


Beacon during CFP 


Data(bc/mc) 


t 


Broadcast or multicast MSDU :J2 


Mgmt(bc) 


I or 2 


Broadcast MMPDU 


Mgmt(dir)-ACK 


2or3 


Directed MMPDU 


Data{dir)+CF-Poll{+CF-Ack} - Data(dir)+CF-Ack 
- (CF-Ack(nodata)} 


2 


Poll and ACK sent with MPDUs 


Data{dir)+CF-Poll{+CF-Ack} - CF-Ack(no data) 


2 


Poll of STA with empty queue, insufficient 
time for queued MPDU, or too little time 
remaining before a dwell or medium occu- 
pancy boundary to send a queued frame 


CF-Poll(no data){+CF-Ack} - Data(dir)- (CF- 
Ack(no data)} 


2 


Separate poll, ACK sent with MPDU 


CF-Poll(no data){+CF-Ack} - Data(dir) - ACK 


3 


Polled STA sends to STA in BSS 


CF-Poll(no data){+CF-Ack} - Null(no data) 


2 


Separate poll, STA queue empty, or insuffi- 
cient time for queued MPDU or too little 
time remaining before a dwell or medium 
occupancy boundary to send a queued frame 


Data(dir){+CF-Ack} - ACK 


2 


ACK if not CF-Pollable or not polled 



LEGEND (For Table 21 and Table 22) 



1 — items enclosed in brackets "[. . .]" may occur zero or more times in the sequence. 

2 — Items enclosed ui braces "f.. .' }" may occur zero or one time in the sequence. 

3 — An isolated hyphen represents a SIFS interval separating the pair of frames. 

4— "Data(bc/mc)" represents any frame of type Data with a broadcast or multicast address in the Address 1 field. 

5— "Mgmt(bc)" represents any Management type frame with a broadcast address in the DA field. 

6 — "RTS" represents a Control frame of subtype RTS. 

7 — "CTS" represents a Control frame of subtype CTS. 
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LEGEND (Continued) 

8 — "ACK M represents a Control frame of subtype ACK. 

9 — "Frag" represents an MPDU of type Data or an MMPDU of type Management with an individual address in the 
Address 1 field that has the More Fragments field set to " l. M 

10— "Last" represents an MDPU of type Data or an MMPDU of type Management with an individual address in the 
Address 1 field that has the More Fragments field set to "0." 

1 1 — "PS-Poll" represents a Control frame of subtype PS-Poll. 

12 — "DTIM(CF)" represents a management frame of subtype Beacon that contains a DTIM information element with a 
nonzero value in the CFPDurRemaining field of its Parameter Set element. 

13 — "CF-End" represents a Control frame of type CF-End, or (if the final frame of the immediately preceding <CF- 
Sequence> was a directed data or management frame requiring acknowledgment by the AP) of type CF-End+Ack. 

14 — "Beacon(CF)" represents a management frame of subtype Beacon with a nonzero value in the CFPDurRemaining 
field of its CF Parameter Set element 

15 — "Data(dir)" represents any MPDU of type Data with an individual address in the Address I field. 

16 — "Mgmt(dir)" represents any MMPDU of type Management with an individual address in the Address! field. 

1 7 — "CF-Ack(no data) 7 ' represents a data frame of subtype CF-ACK (no data). 

1 8 — "CF-Poll(no data)" represents a data frame of subtype CF-Poll (no data). 

19 — "Null(no data) TT represents a data frame of subtype Null Function (no data). 

20 — "{+CF-Ack}" indicates that the frame may or may not include a contention-free acknowledgment. 

21 — "+CF-Ack" indicates that the frame includes a contention- free acknowledgment. 

22 — "+CF-Poll" indicates that the frame includes a contention-free poll. 

23 — <CF-Sequence> represents a sequence of one or more frames sent during a CFP. A valid <CF-Sequence> shall con- 
sist of one of the frame sequences shown in Table 22. The collection of sequences of frame exchanges corresponding to 
[<CF-Sequence>] may occur in any order within the CFP. 

Individual frames within each of these sequences are separated by a SIFS. 
9.8 MSOU transmission restrictions 

To avoid reordering MSDUs between pairs of LLC entities and/or unnecessarily discarding MSDUs, the fol- 
lowing restrictions shall be observed by any STA that is able to concurrently process multiple outstanding 
MSDUs for transmission. Note that here the term "outstanding" refers to an MSDU or MMPDU that is eligi- 
ble to be transmitted at a particular time. A STA may have any number (greater than or equal to one) of eligi- 
ble MSDUs outstanding concurrently, subject to the restrictions below. 

The STA shall ensure that no more than one MSDU or MMPDU from a particular SA to a particular individ- 
ual RA is outstanding at a time. Note that a simpler, more restrictive invariant to maintain is that no more 
than one MSDU with a particular individual RA may be outstanding at a time. 

In a STA where the optional StrictlyOrdered service class has been implemented, that STA shall ensure that 
there is no group-addressed (multidestination) MSDU of the StrictlyOrdered service class outstanding from the 
SA of any other outstanding MSDU (either directed or group-addressed). This is because a group-addressed 
MSDU is implicitly addressed to a collection of peer STAs that could include any individual RA. 

It is recommended that the STA select a value of aMaxMSDUTransmitLifetime that is sufficiently large that the 
STA does not discard MSDUs due to excessive Transmit MSDU timeouts under normal operating conditions. 
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10. Layer management 

10.1 Overview of management model 

Both MAC and PHY layers conceptually include management entities, called MAC sublayer management 
and PHY layer management entities (MLME and PLME, respectively). These entities provide the layer 
management service interfaces through which layer management functions may be invoked. 

In order to provide correct MAC operation, a station management entity (SME) shall be present within each 
STA. The SME is a layer-independent entity that may be viewed as residing in a separate management plane 
or as residing "off to the side" The exact functions of the SME are not specified in this standard, but in gen- 
eral this entity may be viewed as being responsible for such functions as the gathering of layer-dependent 
status from the various layer management entities, and similarly setting the value of layer-specific parame- 
ters. SME would typically perform such functions on behalf of general system management entities and 
would implement standard management protocols. Figure 1 1 depicts the relationship among management 
entities. 

The various entities within this model interact in various ways. Certain of these interactions are defined 
explicitly within this standard, via a service access point (SAP) across which defined primitives are 
exchanged. Other interactions are not defined explicitly within this standard, such as the interfaces between 
MAC and MLME and between PLCP and PLME, represented as double arrows within Figure 63. The spe- 
cific manner in which these MAC and PHY management entities are integrated into the overall MAC and 
PHY layers is not specified within this standard. 

The management SAPs within this model are the following: 

— SME-MLMESAP 

— SME-PLME SAP 

— MLME-PLME SAP 

The latter two SAPs support identical primitives, and in fact may be viewed as a single SAP (called the 
PLME SAP) that may be used either directly by MLME or by SME. In this fashion, the model reflects what 
is anticipated to be a common implementation approach in which PLME functions are controlled by the 
MLME (on behalf of SME). In particular, PHY implementations are not required to have separate interfaces 
defined other than their interfaces with the MAC and MLME. 

10.2 Generic management primitives 

The management information specific to each layer is represented as a management information base (MIB) 
for that layer. The MAC and PHY layer management entities are viewed as "containing" the MIB for that 
layer. The generic model of MIB-related management primitives exchanged across the management SAPs is 
to allow the SAP user-entity to either GET the value of a MIB attribute, or to SET the value of a MIB 
attribute. The invocation of a SET.request primitive may require that the layer entity perform certain defined 
actions. 

Figure 63 depicts these generic primitives. 
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Entity 

PLME GET/SET 



PLME 



Figure 63 — GET and SET operations 

The GET and SET primitives are represented as REQUESTS with associated CONFIRM primitives. These 
primitives are prefixed by MLME or PLME depending upon whether the MAC or PHY layer management 
SAP is involved. In the following, XX denotes MLME or PLME: 

XX-GET.request (MIBattribute) 

Requests the value of the given MIBattribute. 

XX-GET.confirm (status, MIBattribute, MIBattributevalue) 

Returns the appropriate MIB attribute value if status = "success," otherwise returns an error indica- 
tion in the Status field. Possible error status values include "invalid MIB attribute" and "attempt to 
get write-only MIB attribute." 

XX-SET.request (MIBattribute, MIBattributevalue) 

Requests that the indicated MIB attribute be set to the given value. If this MIBattribute implies a 
specific action, then this requests that the action be performed. 



XX-SET.confirm (status, MIBattribute) 

If status - "success " this confirms that the indicated MIB attribute was set to the requested value, 
otherwise it returns an error condition in status field. If this MIBattribute implies a specific action, 
then this confirms that the action was performed. Possible error status values include "invalid MIB 
attribute" and "attempt to set read-only MIB attribute." 

Additionally, there are certain requests (with associated confirms) that may be invoked across a given SAP 
that do not involve the setting or getting of a specific MIB attribute. One of these is supported by each SAP, 
as follows: 

— XX- RESET. request: where XX is MLME or PLME as appropriate 

— XX-RESET.confirm 



This service is used to initialize the management entities, the MIBs, and the datapath entities. It may include 
a list of attributes for items to be initialized to non-default values. The corresponding .confirm indicates suc- 
cess or failure of the request. 

Other SAP-specific primitives are identified in 10.3. 
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10.3 MLME SAP interface 

The services provided by the MLME to the SME are specified in this subclause. These services are described 
in an abstract way and do not imply any particular implementation or exposed interface. MLME SAP primi- 
tives are of the general form ACTION. request followed by ACT I ON. con firm. The SME uses the services 
provided by the MLME through the MLME SAP. 

10.3.1 Power management 

This mechanism supports the process of establishment and maintenance of the power management mode of 
a STA. 

10.3.1.1 MLME-POWERMGT.request 

10.3.1.1.1 Function 

This primitive requests a change in the power management mode. 

1 0.3.1 .1 .2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-POWERMGT.request ( 

PowerManagementMode, 

WakeUp, 

ReceiveDTIMs 

) 



Name 


Type 


Valid range 


Description 


PowerManagementMode 


Enumeration 


ACTIVE, 
POWER_SAVE 


An enumerated type that describes the desired 
power management mode of the STA. 


WakeUp 


Boolean 


True, false 


When true, the MAC is forced immediately into 
the Awake state. This parameter has no effect if 
the current power management mode is 
ACTIVE. 


ReceiveDTIMs 


Boolean 


True, false 


When true, this parameter causes the STA to 
awaken to receive all DTIM frames. When 
false, the STA is not required to awaken for 
every DTIM frame. 



10.3.1. 1.3 When generated 



This primitive is generated by the SME to implement the power-saving strategy of an implementation. 
1 0.3.1 . 1 .4 Effect of receipt 

This request sets the STA's power management parameters. The MLME subsequently issues a MLME- 
POWERMGT.confirm that reflects the results of the power management change request. 

10.3.1.2 MLME-POWERMGT.confirm 

10.3.1.2.1 Function 

This primitive confirms the change in power management mode. 
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10.3.1.2.2 Semantics of the service primitiv 

The primitive parameters are as follows: 



MLME-POWERMGT.confirm ( 

RcsultCode 
) 



Name 


Type 


Valid range | Description 


ResultCode 


Enumeration 


SUCCESS, 

INVALID PARAMETERS, 
NOT SUPPORTED 


Indicates the result of the 
ML ME-POWERMGT. request 



10.3.1. 2.3 When generated 



This primitive is generated by the MLME as a result of an MLME-POWERMGT.request to establish a new 
power management mode. It is not generated until the change has completed. 

10.3.1.2.4 Effect of receipt 

The SME is notified of the change of power management mode. 
10.3.2 Scan 

This mechanism supports the process of determining the characteristics of the available BSSs. 
10.3.2.1 MLME-SCAN. request 

10.3.2.1.1 Function 

This primitive requests a survey of potential BSSs that the STA may later elect to try to join. 

10.3.2.1.2 Semantics of the service primitive 

The primitive parameters are as follows: 

ML ME- SCAN, request ( 

BSSType, 

BSSID, 

SSID, 

ScanType, 

ProbeDelay, 

ChannelList, 

MinChannelTime, 

MaxChannelTime 

) 
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Name 


Type 


Valid range | Description 


BSSType 


Enumeration 


INFRASTRUCTURE, 

INDEPENDENT, 

ANY_BSS 


Determines whether Infrastructure BSS, 
Independent BSS, or both, are included in 
the scan 


BSSID 


MAC Address 


Any valid individual or 
broadcast MAC address 


Identifies a specific or broadcast BSSID 


SSID 


Octet string 


0-32 octets 


Specifies the desired SSID or the . 


ScanType 


Enumeration 


ACTIVE, 
PASSIVE 


Indicates either active or passive scanning 


ProbeDelay 


Integer 


N/A 


Delay (in us) to be used prior to 
transmitting a Probe frame during active 
scanning 


ChannclList 


Ordered set of 
integers 


Each channel will be 
selected from the valid 
channel range for the 
appropriate PHY and 
carrier set. 


Specifies a list of channels that are 
examined when scanning for a BSS 


M i nCh annelTime 


Integer 


> ProbeDelay 


The minimum time (in TU) to spend on 
each channel when scanning 


MaxChannelTime 


Integer 


> MinChannelTime 


The maximum time (in TU) to spend on 
each channel when scanning 



10.3.2.1.3 When generated 



This primitive is generated by the SME for a STA to determine if there are other BSSs that it may join. 
10.3.2.1.4 Effect of receipt 

This request initiates the scan process when the current frame exchange sequence is completed. 
10.3.2.2 MLME-SCAN. confirm 

10.3.2.2.1 Function 

This primitive returns the descriptions of the set of BSSs detected by the scan process. 

1 0.3.2.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-SCAN.confirm ( 

BSSDescriptionSet, 

ResultCode 

) 



Name 


Type 


Valid range 


Description 


BSSDescriptionSet 


Set of BSSDescriptions 


N/A 


The BSSDescriptionSet is returned to 
indicate the results of the scan request. It 
is a set containing zero or more instances 
of a BSSDescription. 


ResultCode 


Enumeration 


SUCCESS, 
INVALID. 
PARAMETERS 


Indicates the result of the MLME- 
SCAN.confirm 
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Each BSSDescription consists of the following elements: 



Name 


Type 


Valid range 


Description 


BSSID 


MAC Address 


N/A 


The BSSID of the found BSS 


SSID 


Octet string 


1-32 octets 


The SSID of the found BSS 


BSSType 


Enumeration 


INFRASTRUCTURE, 
INDEPENDENT 


The type of the found BSS 


Beacon Period 


Integer 


N/A 


The Beacon period of the found BSS (in 
TU) 


DTIM Period 


Integer 


As defined in frame 
format 


The DTIM period of the BSS (in 
beacon periods) 


Timestarnp 


Integer 


N/A 


The timestarnp of the received frame 
(probe response/beacon) from the found 
BSS 


Local Time 


Integer 


N/A 


The value of the STA's TSF timer at the 
start of reception of the first octet of the 
iiiiicMaiiip nciu ui me received iiuinc 
(probe response or beacon) from the 
found BSS 


PHY parameter set 


As defined in 
frame format 


As defined in frame 
format 


The parameter set relevant to the PHY 


r parameter sci 


Ac in 

/a. 3 ueimeu in 
frame format 


As defined in frame 
format 


The parameter set for the CF periods, if 
found BSS supports CF mode 


IBSS parameter set 


As defined in 
frame format 


As defined in frame 
format 


The parameter set for the IBSS, if found 
BSS is an IBSS 


Capability Information 


As defined in 
frame format 


As defined in frame 
format 


The advertised capabilities of the BSS 


BSSBasicRateSet 


Set of integers 


2-127 inclusive (for 
each integer in the set) 


The set of data rates ( in units of 
500 kb/s) that must be supported by all 
STAs that desire to join this BSS. The 
STAs must be able to receive at each of 
the data rates listed in the set. 



10.3.2.2.3 When generated 



This primitive is generated by the MLME as a result of an MLME-SCAN.request to ascertain the operating 
environment of the STA. 

10.3.2.2.4 Effect of receipt 

The SME is notified of the results of the scan procedure. 
10.3.3 Synchronization 

This mechanism supports tfie process of selection of a peer in the authentication process. 
10.3.3.1 MLME-JOIN. request 
10.3.3.1.1 Function 

This primitive requests synchronization with a BSS. 
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10.3.3.1.2 Semantics of the servic primitive 

The primitive parameters are as follows: 

MLME-JOINxequest ( 

BSSDescription, 
JoinFailureTimeout, 
ProbeDelay. 
OperationalRateSet 

^ ) 



Name 


Type 


Valid range 


Description 


BSSDescription 


BSSDescription 


N/A 


The BSSDescription of the BSS to join. The 
BSSDescription is a member of the set of 
descriptions that was returned as a result of a 
MLME-SCAN. request. 


JoinFailureTimeout 


Integer 


>l 


The time limit, in units of beacon intervals, after 
which the join procedure will be terminated 


ProbeDelay 


Integer 


N/A 


Delay (in us) to be used prior to transmitting a 
Probe frame during active scanning 


OperationalRateSet 


Set of integers 


2- 1 27 inclusive 
(for each integer 
in the set) 


The set of data rates (in units of 500 kbit/s) that the 
STA may use for communication within the BSS. 
The STA must be able to receive at each of the data 
rates listed in the set. The OperationalRateSet is a 
superset of the BSSBasicRateSet advertised by the 
BSS. 



10.3.3.1.3 When generated 



This primitive is generated by the SME for a STA to establish synchronization with a BSS. 
1 0.3.3.1 .4 Effect of receipt 

This primitive initiates a synchronization procedure once the current frame exchange sequence is complete. 
The MLME synchronizes its timing with the specified BSS based on the elements provided in the BSSDe- 
scription parameter. The MLME subsequently issues a MLME-JOIN.confirm that reflects the results. 

10.3.3.2 MLME-JOIN.confirm 

10.3.3.2.1 Function 

This primitive confirms synchronization with a BSS. 

10.3.3.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-JOIN.confirm ( 

ResultCode 
) 



Name 


Type 


Valid range 


Description 


ResultCode 


Enumeration 


SUCCESS, 

INVALID PARAMETERS, 
TIMEOUT 


Indicates the result of the MLME-JOlN.request 
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10.3.3.2.3 When generated 

This primitive is generated by the MLME as a result of an MLME-JOIN.request to establish synchronization 
with a BSS. 

10.3.3.2.4 Effect of receipt 

The SME is notified of the results of the synchronization procedure. 
10.3.4 Authenticate 

This mechanism supports the process of establishing an authentication relationship with a peer MAC entity. 
1 0.3.4.1 MLME-AUTHENTICATE. request 

10.3.4.1.1 Function 

This primitive requests authentication with a specified peer MAC entity. 

10.3.4.1.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME- AUTHENTIC ATE.request ( 

PeerSTAAddress, 
AuthenticationType, 
AuthenticateFailureTimeout 
) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MACAddress 


Any valid 
individual MAC 
address 


Specifies the address of the peer MAC entity 
with which to perform the authentication 
process 


AuthenticationType 


Enumeration 


OPEN.SYSTEM, 
SHARED. KEY 


Specifies the type of authentication algorithm \ 
to use during the authentication process 


Authentication Failure- 
Timeout 


Integer 


>l 


Specifies a time limit (in TU) after which the 
authentication procedure will be terminated 



10.3.4.1.3 When generated 



This primitive is generated by the SME for a STA to establish authentication with a specified peer MAC 
entity in order to permit Class 2 frames to be exchanged between the two STAs. During the authentication 
procedure, the SME may generate additional MLME-AUTHENTICATE. request primitives. 

10.3.4.1.4 Effect of receipt 

This primitive initiates an authentication procedure. The MLME subsequently issues a MLME-AUTHENTI- 
CATE. confirm that reflects the results. 

10.3.4.2 MLME-AUTHENTICATE. confirm 

10.3.4.2.1 Function 

This primitive reports the results of an authentication attempt with a specified peer MAC entity. 
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10.3.4.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-AUTHENTICATE.confirm ( 

PeerSTAAddress, 

AuthenticationType, 

ResultCode 

) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MAC Address 


Any valid individual 
MAC address 


Specifies the address of the peer MAC entity 
with which the authentication process was 
attempted. This value must match the peer- 
STAAddress parameter specified in the corre- 
sponding MLME-AUTHENTICATE.request. 


AuthenticationType 


Enumeration 


OPEN_SYSTEM, 
SHAREDJCEY 


Specifies the type of authentication algorithm 
that was used during the authentication process. 
This value must match the authenticationType 
parameter specified in the corresponding 
MLME-AUTHENTICATE.request. 


ResultCode 


Enumeration 


SUCCESS, INVALID, 

PARAMETERS, 

TIMEOUT, 

TOO_MANY_ 

SIMULTANEOUS 

REQUESTS, 

REFUSED 


Indicates the result of the MLME-AUTHENTI- 
CATE.request. 



10.3.4.2.3 When generated 



This primitive is generated by the MLME as a result of an MLME-AUTHENTICATE.request to authenticate 
with a specified peer MAC entity. 

10.3.4.2.4 Effect of receipt 

The SME is notified of the results of the authentication procedure. 
10.3.4.3 MLME-AUTHENTICATE. indication 

10.3.4.3.1 Function 

This primitive reports the establishment of an authentication relationship with a specific peer MAC entity. 

10.3.4.3.2 Semantics, of-the service primitive 

The primitive parameters are as follows: 

MLME- AUTHENTIC ATE.indication ( 

PeerSTAAddress, 

AuthenticationType 

) 
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Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MAC Address 


Any valid individ- 
ual MAC address 


Specifies the address of the peer MAC entity 
with which the authentication relationship was 
established 


AuthenticationType 


Enumeration 


OPEN_SYSTEM, 
SHAREDJCEY 


Specifies the type of authentication algorithm 
that was used during the authentication process 



10.3.4.3.3 When generated 



This primitive is generated by the MLME as a result of the establishment of an authentication relationship 
with a specific peer MAC entity that resulted from an authentication procedure that was initiated by that spe- 
cific peer MAC entity. 

1 0.3.4.3.4 Effect of receipt 

The SME is notified of the establishment of the authentication relationship. 
10.3.5 De-authenticate 

This mechanism supports the process of invalidating an authentication relationship with a peer MAC entity. 
10.3.5.1 MLME-DEAUTHENTICATE. request 

10.3.5.1.1 Function 

This primitive requests that the authentication relationship with a specified peer MAC entity be invalidated. 

10.3.5.1.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-DEAUTHENTICATE.request ( 

PeerSTAAddress, 

ReasonCode 

) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MACAddress 


Any valid 
individual 
MAC address 


Specifies the address of the peer MAC entity with which 
to perform the deauthentication process 


ReasonCode 


As defined in 
frame format 


As defined in 
frame format 


Specifies the reason for initiating the deauthentication 
procedure 



10.3.5.1.3 When generated 



This primitive is generated by the SME for a STA to invalidate authentication with a specified peer MAC 
entity in order to prevent the exchange of Class 2 frames between the two STAs. During the deauthentication 
procedure, the SME may generate additional MLME-DEAUTHENTICATE.request primitives. 

1 0.3.5.1 .4 Effect of receipt 

This primitive initiates a deauthentication procedure. The MLME subsequently issues a MLME-DE- 
AUTHENTICATE.confirm that reflects the results. 
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10.3.5.2 MLME-DEAUTHENTICATE. confirm 

10.3.5.2.1 Functi n 

This primitive reports the results of a deauthentication attempt with a specified peer MAC entity. 

10.3.5.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-DEAUTH ENTIC ATE. confirm ( 

PeerSTAAddress, 
ResultCode 

) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MACAddress 


Any valid individual MAC 
address 


Specifies the address of the peer MAC 
entity with which the deauthentication pro- 
cess was attempted 


ResultCode 


Enumeration 


SUCCESS. 

INVALID_PARA METERS, 
TOO.MANY SIMUL- 
TANEOUS.REQUESTS 


Indicates the result of the 
MLME-DEAUTHENTICATE.request 



10.3.5.2.3 When generated 



This primitive is generated by the MLME as a result of an MLME-DEAUTHENTICATE.request to invali- 
date the authentication relationship with a specified peer MAC entity. 

10.3.5.2.4 Effect of receipt 

The SME is notified of the results of the deauthentication procedure. 
10.3.5.3 MLME-DEAUTHENTICATE. indication 

10.3.5.3.1 Function 

This primitive reports the invalidation of an authentication relationship with a specific peer MAC entity. 

1 0.3.5.3.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-DEAUTH ENTIC ATE. indication ( 

PeerSTAAddress, 

ReasonCode 

) 
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Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MAC Address 


Any valid 
individual MAC 
address 


Specifies the address of the peer MAC entity with 
which the authentication relationship was 
invalidated 


ReasonCode 


As defined in 
frame format. 


As defined in 
frame format 


Specifies the reason the deauthentication procedure 
was initiated 



10.3.5.3.3 When generated 



This primitive is generated by the MLME as a result of the invalidation of an authentication relationship 
with a specific peer MAC entity. 

1 0.3.5.3.4 Effect of receipt 

The SME is notified of the invalidation of the specific authentication relationship. 
10.3.6 Associate 

The following primitives describe how a STA becomes associated with an access point (AP). 
10.3.6.1 MLME-ASSOCIATE. request 

10.3.6.1.1 Function 

This primitive requests association with a specified peer MAC entity that is acting as an A P. 

10.3.6.1.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-ASSOCIATE. request ( 

PeerSTAAddress, 

AssociateFailureTimeout, 

Capabilitylnformation, 

Listen Interval 

) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MACAddress 


Any valid individ- 
ual MAC address 


Specifies the address of the peer MAC entity 
with which to perform the association process 


AssociateFailureTimeout 


Integer 


>1 


Specifies a time limit (in TU) after which the 
associate procedure will be terminated 


Capabilitylnformation 


-As defined in 
frame format 


As defined in 
frame format 


Specifies the operational capability definitions 
to be used by the MAC entity 


Listenlnterval 


Integer 


>0 


Specifies the number of beacon intervals that 
may pass before the STA awakens and listens 
for the next beacon 



10. 3.6.1. 3 When generated 



This primitive is generated by the SME when a STA wishes to establish association with an AP. 
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1 0.3.6.1 .4 Effect of receipt 

This primitive initiates an association procedure. The MLME subsequently issues an MLME-ASSOCI- 
ATE. confirm that reflects the results. 

10.3.6.2 MLME-ASSOCIATE. confirm 

10.3.6.2.1 Function 

This primitive reports the results of an association attempt with a specified peer MAC entity that is acting as 
an AP. 

10.3.6.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 



MLME-ASSOCIATE.confirm ( 

ResultCode 
) 



Name 


Type 


Valid range 


Description 


ResultCode 


Enumeration 


SUCCESS, 
INVALID. 
PARAMETERS, 

TIMEOUT, 
REFUSED 


Indicates the result of the MLME-ASSOCI- 
ATE. request 



10.3.6.2.3 When generated 



This primitive is generated by the MLME as a result of an MLME-ASSOCIATE.request to associate with a 
specified peer MAC entity that is acting as an AP. 

1 0.3.6.2.4 Effect of receipt 

The SME is notified of the results of the association procedure. 
10.3.6.3 MLME-ASSOCIATE.indication 

10.3.6.3.1 Function 

This primitive reports the establishment of an association with a specific peer MAC entity. 

10.3.6.3.2 Semantics of the service primitive 
The primitive parameters are as follows: 



MLME-ASSOCIATE.indication ( 

PeerSTAAddress 
) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MACAddress 


Any valid individual 
MAC address 


Specifies the address of the peer MAC entity with 
which the association was established 



no 
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10.3.6.3.3 When generated 

This primitive is generated by the MLME as a result of the establishment of an association with a specific 
peer MAC entity that resulted from an association procedure that was initiated by that specific peer MAC 
entity. 

10.3.6.3.4 Effect of receipt 

The SME is notified of the establishment of the association. 
10.3.7 Reassociate 

The following primitives describe how a STA becomes associated with another AP. 
10.3.7.1 MLME-REASSOCIATE. request 

10.3.7.1.1 Function 

This primitive requests a change in association to a specified new peer MAC entity that is acting as an AP. 

10.3.7.1.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME- REASSOCIATE. request ( 

NewAPAddress, 
Reassoc iateFa i lureTimeo ut, 
Capabilitylnformation, 
Listen Interval 

) 



Name 


Type 


Valid range 


Description 


NewAPAddress 


MACAddress 


Any valid indi- 
vidual MAC 
address 


Specifies the address of the peer MAC 
entity with which to perform the 
reassociation process 


Reassoc lateFailureTimeout 


Integer 


>l 


Specifies a time limit (in TU) after which 
the reassociate procedure will be 
terminated 


Capability Information 


As defined in 
frame format 


As defined in 
frame format 


Specifies the operational capability 
definitions to be used by the MAC entity 


Listenlnterval 


Integer 


>0 


Specifies the number of beacon intervals 
that may pass before the STA awakens and 
listens for the next beacon. 



10.3.7.1. 3 When generated 



This primitive is generated by the SME for a STA to change association to a specified new peer MAC entity 
that is acting as an AP. 

1 0.3.7.1 .4 Effect of receipt 

This primitive initiates a reassociation procedure. The MLME subsequently issues a MLME-REASSOCI- 
ATE. confirm that reflects the results. 
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10.3.7.2 MLME-REASSOCIATE. confirm 

10.3.7.2.1 Function 

This primitive reports the results of a reassociation attempt with a specified peer MAC entity that is acting as 
an AP. 

10.3.7.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 



MLME-REASSOCIATExonfirm ( 

ResultCode 

) 



Name 


Type 


Valid range 


Description 


ResultCode 


Enumeration 


SUCCESS, 

INVALID. 

PARAMETERS, 

TIMEOUT, 

REFUSED 


Indicates the result of the MLME-REASSOCI- 
ATE. request 



10.3.7.2.3 When generated 



This primitive is generated by the MLME as a result of an MLME-REASSOCIATE.request to reassociate 
with a specified peer MAC entity that is acting as an A P. 

10.3.7.2.4 Effect of receipt 

The SME is notified of the results of the reassociation procedure. 
10.3.7.3 MLME-REASSOCIATE.indication 

10.3.7.3.1 Function 

This primitive reports the establishment of a reassociation with a specified peer MAC entity. 

10.3.7.3.2 Semantics of the service primitive 
The primitive parameters are as follows: 



MLME-REASSOCIATE.indication ( 

PeerSTAAddress 
) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MACAddress 


Any valid individual 
MAC address 


Specifies the address of the peer MAC entity with 
which the reassociation was established 



10.3.7.3.3 When generated 



This primitive is generated by the MLME as a result of the establishment of a reassociation with a specific 
peer MAC entity that resulted from a reassociation procedure that was initiated by that specific peer MAC 
entity. 
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10.3.7.3.4 Effect of r ceipt 

The SME is notified of the establishment of the reassociation. 
10.3.8 Disassociate 

1 0.3.8.1 MLME-DISASSOCIATE. request 

10.3.8.1.1 Function 

This primitive requests disassociation with a specified peer MAC entity that is acting as an AP. 

10.3.8.1.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-DISASSOCIATE.request ( 

PeerSTAAddress, 

ReasonCode 

) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MACAddress 


Any valid individual 
MAC address 


Specifies the address of the peer MAC entity with 
which to perform the disassociation process 


ReasonCode 


As defined in 
frame format 


As defined in frame 
format 


Specifies the reason for initiating the disassociation 
procedure 



10.3.8.1. 3 When generated 



This primitive is generated by the SME for a STA to establish disassociation with an AP. 
10.3.8.1.4 Effect of receipt 

This primitive initiates a disassociation procedure. The MLME subsequently issues an MLME-DISASSO- 
CIATE. confirm that reflects the results. 

1 0.3.8.2 MLME-DISASSOCIATE. confirm 

10.3.8.2.1 Function 

This primitive reports the results of a disassociation procedure with a specific peer MAC entity that is acting 
as an AP. 

1 0.3.8.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-DISASSOCIATExonfirm ( 

ResultCode 

) 
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Name | Type 


Valid range 


Description 


ResultCode 


Enumeration 


SUCCESS, 

INVALID. 

PARAMETERS, 

TIMEOUT, 

REFUSED 


Indicates the result of the MLME-DISASSOCIATE. request 



10.3.8.2.3 When generated 



This primitive is generated by the MLME as a result of an ML ME- DISASSOCIATE. request to disassociate 
with a specified peer MAC entity that is acting as an AP. 

1 0.3.8.2.4 Effect of receipt 

The SME is notified of the results of the disassociation procedure. 
1 0.3.8.3 MLME-DISASSOCIATE.indication 

10.3.8.3.1 Function 

This primitive reports disassociation with a specific peer MAC entity. 

10.3.8.3.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-DISASSOCIATE.indication ( 

PeerSTAAddress, 

ReasonCode 

) 



Name 


Type 


Valid range 


Description 


PeerSTAAddress 


MACAddress 


Any valid individual 
MAC address 


Specifies the address of the peer MAC entity with 
which the association relationship was 
invalidated 


ReasonCode 


As defined in 
frame format 


As defined in frame 
format 


Specifies the reason the disassociation procedure 
was initiated 



10.3.8.3.3 When generated 



This primitive is generated by the MLME as a result of the invalidation of an association relationship with a 
specific peer MAC entity. 

10.3.8.3.4 Effect of receipt 

The SME is notified of the invalidation of the specific association relationship. 
10.3.9 Reset 

This mechanism supports the process of resetting the MAC. 
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10.3.9.1 MLME-RESET.request 

10.3.9.1.1 Function 

This primitive requests that the MAC entity be reset. 

10.3.9.1.2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-RESET.request ( 

STAAddress, 
SetDefaultMIB 

) 



Name 


Type 


Valid range 


Description 


STAAddress 


MACAddress 


Any valid 
MAC address 


Specifies the MAC address that is to be used by the MAC 
entity that is being reset. This value may be used to pro- 
vide a locally administered STA address. 


SetDefaultMIB 


Boolean 


True, false 


If true, all MIB attributes are set to their default values. 
The default values are implementation dependent. 
If false, the MAC is reset, but all MIB attributes retain the 
values that were in place prior to the generation of the 
MLME-RESET.request primitive. 



10.3.9.1. 3 When generated 



This primitive is generated by the SME to reset the MAC to initial conditions. The MLME-RESET.request 
primitive must be used prior to use of the MLME-START.request primitive. 

10.3.9.1.4 Effect of receipt 

This primitive sets the MAC to initial conditions* clearing ail internal variables to the default values. MIB 
attributes may be reset to their implementation-dependent default values by setting the SetDefaultMIB flag 
to true. The MLME subsequently issues a MLME-RESET.confirm that reflects the results. 

10.3.9.2 MLME-RESET.confirm 

10.3.9.2.1 Function 

This primitive reports the results of a reset procedure. 

10.3.9.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 



MLME-RESET.confirm ( 

ResultCode 
) 



Name 


Type 


Valid range 


Description 


ResultCode | Enumeration 


SUCCESS 


Indicates the result of the MLME-RESET.request 
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10.3.9.2.3 When generated 

This primitive is generated by the MLME as a result of an MLME-RESET.request to reset the MAC entity. 

1 0.3.9.2.4 Effect of receipt 

The SME is notified of the results of the reset procedure. 
10.3.10 Start 

This mechanism supports the process of creating a new BSS. 
10.3.10.1 MLME-START.request 

10.3.10.1.1 Function 

This primitive requests that the MAC entity start a new BSS. 

1 0.3.1 0.1 .2 Semantics of the service primitive 

The primitive parameters are as follows: 

MLME-START.request ( 

SSID, 

BSSType, 

BeaconPeriod, 

DTIMPeriod, 

CF parameter set, 

PHY parameter set, 

IBSS parameter set, 

ProbeDelay. 

Capabilitylnformatton, 

BSSBasicRateSet, 

OperationalRateSet 

) 



Name 


Type 


Valid range 


Description 


SSID 


Octet string 


I -3 2 octets 


The SSID of the BSS 


BSSType 


Enumeration 


INFRA- 
STRUCTURE, 
INDEPEN- 
DENT 


The type of the BSS 


Beacon Period 


Integer 


>l 


The Beacon period of the BSS (in TU) 


DTIM Period 


Integer 


As defined in 
frame format 


The DTIM Period of the BSS (in beacon periods) 


CF parameter set 


As defined in 
frame format 


As defined in 
frame format 


The parameter set forCF periods, if the BSS supports 
CF mode. aCFPPeriod is modified as a side effect of 
the issuance of an MLME-START.request primitive. 


PHY parameter set 


As defined in 
frame format 


As defined in 
frame format 


The parameter set relevant to the PHY 


IBSS parameter set 


As defined in 
frame format 


As defined in 
frame format 


The parameter set for the IBSS, if BSS is an IBSS 
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Name 


Type I Valid range 


Description 


ProbeDelay 


Integer 


N/A 


Delay (in us) to be used prior to transmitting a Probe 
frame during active scanning 


Capabiiitylnforma- 
tion 


As defined in 
frame format 


A< Hpfinpfl in 

Aj VHw LI J IvU Hi 

frame format 


The capabilities to be advertised for the BSS 


BSSBasicRateSet 


Set of integers 


2- 127 inclusive 
(for each inte- 
ger in the set) 


The set of data rates (in units of 500 kbit/s) that must 
be supported by all STAs to join this BSS. The STA 
that is creating the BSS must be able to receive and 
transmit at each of the data rates listed in the set. 


OperationalRateSet 


Set of integers 


2- 1 27 inclusive 
(for each inte- 
ger in the set) 


The set of data rates (in units of 500 kbit/s) that the 
STA may use for communication within the BSS. The 
STA must be able to receive at each of the data rates 
listed in the set. The OperationalRateSet is a superset 
of the BSSBasicRateSet advertised by the BSS. 



10.3.10.1.3 When generated 



This primitive is generated by the SME to start either an infrastructure BSS (with the MAC entity acting as 
an AP), or to start an independent BSS (with the MAC entity acting as the first STA in the IBSS). 

The MLME-START.request primitive must be generated after an MLME-RESET.request primitive has been 
used to reset the MAC entity and before an MLME-JOIN. request primitive has been used to successfully 
join an existing infrastructure BSS or independent BSS. 

The MLME-START.request primitive must not be used after successful use of the MLME-START.request 
primitive or successful use of the MLME-JOIN.request without generating an intervening MLME- 
RESET.request primitive. 

10.3.10.1.4 Effect of receipt 

This primitive initiates the BSS initialization procedure once the current frame exchange sequence is com- 
plete. The MLME subsequently issues an ML ME- START, con firm that reflects the results of the creation 
procedure. 

1 0.3.1 0.2 MLME-START.confirm 

10.3.10.2.1 Function 

This primitive reports the results of a BSS creation procedure. 

10.3.10.2.2 Semantics of the service primitive 

The primitive parameters are as follows: 



MLME-START.coimrm _ ( 

ResultCode 
) 



Name 


Type 


Valid range 


reset Description 


ResultCode 


Enumeration 


SUCCESS, 

INVALID_PARAMETERS, 
BSS ALREADY STARTED 
OR JOINED 


Indicates the result of the MLME- 
START.request 
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10.3.10.2.3 When generated 

This primitive is generated by the MLME as a result of an ML ME- START, request to create a new BSS. 

10.3.10.2.4 Effect of receipt 

The SME is notified of the results of the BSS creation procedure. 
10.4 PLME SAP interface 

The PHY management service interface consists of the generic PLMEGET and PLMESET primitives on 
PHY MIB attributes, as described previously, together with the PLME-RESET and PLME-CHARACTER- 
ISTICS primitives and the following specific primitives. 

10.4.1 PLME-RESET.request 

10.4.1.1 Function 

This primitive shall be a request by the LME to reset the PHY The PHY shall be always reset to the receive 
state to avoid accidental data transmission, 

10.4.1.2 Semantics of the service primitive 

The semantics of the primitive are as follows: 

PLME-RESET.request ( ) 
There are no parameters associated with this primitive. 

10.4.1.3 When generated 

This primitive shall be generated at any time to reset the PHY 

1 0.4.1 .4 Effect of receipt 

Receipt of this primitive by the PHY sublayer shall cause the PHY entity to reset both the transmit and the 
receive state machines and place the PHY into the receive state. 

10.4.2 PLME-CHARACTERISTICS. request 

10.4.2.1 Function 

This primitive is a request by the LME to provide the PHY operational characteristics. 

10.4.2.2 Semantics of the service primitive 

The semantics of the primitive are as follows: 

PLME-CHARACTERISTICS.request ( ) 
There are no parameters associated with this primitive. 
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10.4.2.3 When generated 

This primitive is generated by the LME, at initialization time, to request the PHY entity to provide its opera- 
tional characteristics. 

10.4.2.4 Effect of receipt 

The effect of receipt of this primitive by the PHY entity will be to generate a PLME-CHARACTERJSTICS. 
confirm primitive that conveys its operational characteristics. 

10.4.3 PLME-CHARACTERISTICS. confirm 

10.4.3.1 Function 

This primitive provides the PHY operational parameters. 

10.4.3.2 Semantics of the service primitive 

The primitive provides the following parameters: 

PLME-CHARACTERISTICSxonfirm( 

aSlotTime, 

aSIFSTime, 

aCCATime, 

aRxTxTurnaroundTime, 

aTxPLCPDelay, 

aRxPLCPDelay, 

aRxTxSwitchTime, 

aTxRampOnTime, 

aTxRampOfTTirne, 

aTxRFDelay, 

aRxRFDelay, 

aAirPropagationTime, 

aMACProcessingDelay, 

aPreamble Length, 

aPLCPHeaderLength, 

aMPDUDurationFactor, 

aMPDUMaxLength, 

aCWmin, 

aCWmax 

) 
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Name 


I Type 


| Description 


aSlotTime 


integer 


The Slot Time (in us) that the MAC will use for defining the PIFS and DIFS periods See 
9.2.10. 


aoiro i ime 


integer 


The nominal time (in us) that the MAC and PHY will require to receive the last symbol of a 
frame at the air interface, process the frame, and respond with the first symbol on the air 

interfhcP Of thf* PHrlip^t nnccihlp rp cnnncp tnmp C*»*» Q 1 1A 
iJiiwiav,t. \.u nit tallica l JJUSMUIC IC^puriaC inline. Jtt 7.A.1U. 


aCCATime 


integer 


The minimum time (in us) the CCA mechanism has available to assess the medium within 
everv time slot to determinp whpthpr thp mprliiim ic hnc\/ r\r \A\t* 


aRxTxTum- 
aroundTime 


integer 


The maximum time (in us) that the PHY requires to change from receiving to transmit- 
img Hie sidii ui uic ium iymuoi. i ne lonowing equation is used to derive the RxTxTum- 
aroundTime: 

aTxPLCPDelay + aRxTxSwitchTime + aTxRampOnTime + aTxRFDelay. 


aTxPLCPDelay 


integer 


The nominal time (in us) that the PLC P uses to deliver a symbol from the MAC interface 
to the transmit data path of the PMD. 


aRxPLCPDelay 


integer 


The nominal time ( in us) that the PLCP uses to deliver a bit from the PMD receive path to 
the MAC. 


aRxTxSwitch- 
Time 


integer 


i ne nominal nmc (in usj inai tne riviu iaxes to switcn trom Keceive to I ransmit. 


aTx RampOnTime 


integer 


The maximum time (in us) that the PMD takes to turn the Transmitter on. 


aTxRampOflTime 


integer 


The nominal time (in us) that the PMD takes to turn the Transmit Power Amplifier off. 


aTxRFDelay 


integer 


The nominal time (in us) between the issuance of a PMD-DATA.request to the PMD and 
the start of the corresponding symbol at the air interface. The start of a symbol is defined 
to be 1/2 symbol period prior to the center of the symbol for FH, or 1/2 chip period prior 
to the center of the first chip of the symbol for DS, or 1/2 slot time prior to the center of 
the corresponding slot for IR. 


aKxRr Delay 


integer 


The nominal time (in us) between the end of a symbol at the air interface to the issuance 
of a PMD- DATA, indicate to the PLCP. The end of a symbol is defined to be 1/2 symbol 
period after the center of the symbol for FH, or 1/2 chip period after the center of the last 
cnip ui uic ^yrnooi ior ua, or i/z siot time aner me center or tne corresponding slot tor 
IR. 


aAirPropagation- 
Time 


integer 


The anticipated time (in us) it takes a transmitted signal to go from the transmitting sta- 

HUH IxJ UIC ICUC1V1J1H Maiion* 


aMACProcess- 
ingDelay 


integer 


The nominal time (in us) that the MAC uses to process a frame and prepare a response to 
the frame. 


aPreambleLength 


integer 


The current PHY's Preamble Length (in us). If the actual value of the length of the mod- 
ulated preamble is not an integral number of microseconds, the value shall be rounded up 
to the next higher value. 


aPLCPHeader- 
Length 


integer 


The current PHY's PLCP Header Length (in us). If the actual value of the length of the 
modulated header is not an integral number of microseconds, the value shall be rounded 
up to the next higher value. 


aMPDUDuration- 
Factor 


integer 


The overhead added by the PHY to the MPDU as it is transmitted through the wireless 
medium expressed as a scaling factor applied to the number of bits in the MPDU. The 
value of aMPDUDurationFactor is generated by the following equation: 
Truncate[((PPDUbits/PSDUbits>-l) x 10 9 )]. 

The total time to transmit a PPDU over the air is generated by the following equation 
rounded up to the next integer us: 

aPreambleLength + aPLCPHeaderLength + ( ( (aMPDUDurationFactor x8x PSDUoc- 
tets) / 10 9 ) + (8 x PSDUoctets) ) / data rate 
where data rate is in Mbit/s. 

The total time (in us) to the beginning of any octet in a PPDU from the first symbol of the 
-preamble can be calculated using the duration factor in the following equation: 
Truncate[aPreambleLength + aPLCPHeaderLength + ( ( (aMPDUDurationFactor x 8 x 
N)/ 10 9 ) + (8xN))/data rate] + I, 

where data rate is in Mbit/s and where Accounts the number of octets in the PPDU prior to 
the desired octet, but does not count the number of octets in the preamble PLCP Header. 


aMPDU Max- 
Length 


integer 


The maximum number of octets in an MPDU that can be conveyed by a PLCPPDU. 


aCWmin 


integer 


The minimum size of the contention window, in units of aSlotTime. 


aCWmax 


integer 


The maximum size of the contention window, in units of aSlotTime. 
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10.4.3.3 When generated 

This primitive will be issued by the PHY entity in response to a PLME-CHARACTERISTICS. request. 

10.4.3.4 Effect of receipt 

The receipt of this primitive provides the operational characteristics of the PHY entity. 
1 0.4.4 PLME-DSSSTESTMODE. request 

10.4.4.1 Function 

This primitive requests that the DSSS PHY entity enter a test mode operation. The parameters associated 
with this primitive are considered as recommendations and are optional in any particular implementation. 

1 0.4.4.2 Semantics of the service primitive 

The primitive parameters are as follows: 

PLME-DSSSTESTMODE.request ( 

TEST.ENABLE, 

TEST.MODE, 

SCRAMBLE_STATE, 

SPREADING_STATE, 

DATAJTYPE, 

DATA.RATE; 

) 



Name 


Type 


Valid range 


Description 


TEST.ENABLE 


Boolean 


True, false 


If true, enables the PHY test mode according to the 
remaining parameters 


TEST_MODE 


integer 


1,2,3 


TEST_MODE selects one of three operational 
states: 

01 = transparent receive 

02 = continuous transmit 

03 - 50% duty cycle 


SCRAM B L E_STAT E 


Boolean 


True, false 


If true, sets the operational state of the scrambler to 
ON 


SPREADING_STATE 


Boolean 


True, false 


If true, selects the operational state of the chipping 


DATA.TYPE 


integer 


1,2,3 


Selects one of three data patterns to be used for the 
transmit portions of the tests 


DATA.RATE 


integer 


2,4 


Selects between 1 and 2 Mbit/s operation 
02 = I Mbit/s 
04 = 2 Mbit/s 



10.4.4.3 When generated 



This primitive shall be generated at any time to enter the DSSS PHY test mode. 
10.4.4.4 Effect of receipt 

Receipt of this primitive by the PHY sublayer shall cause the DSSS PHY entity to enter the test mode of 
operation. 
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1 0.4.5 PLME-DSSSTESTOUTPUT.request 

10.4.5.1 Function 

This optional primitive shall be a request by the LME to enable selected test signals from the PHY The 
parameters associated with this primitive are considered as recommendations and are optional in any partic- 
ular implementation, 

10.4.5.2 Semantics of the service primitive 

The primitive parameters are as follows: 



PLME-DSSSTESTOUTPUT.request ( 

TEST.OUTPUT, 

) 



Name 


Type 


Valid range 


Description 


TEST.OUTPUT 


Boolean 


True, false 


If true, enables the selected test signals for testing DS PHY 



TEST_OUTPUT enables and disables selected signals for debugging and testing the PHY. Some signals that 
may be available for output are PHY-TXSTART.request, PHY-RX START. indicate(RX VECTOR), PHY- 
CC A. indicate, the chipping clock, the data clock, the symbol clock, TX data, and RX data. 



10.4.5.3 When generated 

This primitive shall be generated at any time to enable the test outputs when in the DSSS PHY test mode. 

1 0.4.5.4 Effect of receipt 

Receipt of this primitive by the DSSS PHY sublayer shall cause the DSSS PHY entity to enable the test 
outputs using the modes set by the most recent PLME-DSSSTESTMODE. request primitive. 
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11. MAC sublayer management entity 
11.1 Synchronization 

All STAs within a single BSS shall be synchronized to a common clock using the mechanisms defined 
herein. 

11.1.1 Basic approach 

A timing synchronization function (TSF) keeps the timers for all STAs in the same BSS synchronized. All 
STAs shall maintain a local TSF timer. 

11.1.1.1 TSF for infrastructure networks 

In an infrastructure network, the AP shall be the timing master and shall perform the TSF. The AP shall ini- 
tialize its TSF timer independently of any simultaneously started APs in an effort to minimize the synchroni- 
zation of the TSF timers of multiple APs. The AP shall periodically transmit special frames called beacons 
that contain a copy of its TSF timer to synchronize the other STAs in a BSS. A receiving STA shall always 
accept the timing information in beacons sent from the AP servicing its BSS. If a STA's TSF timer is differ- 
ent from the timestamp in the received beacon, the receiving STA shall set its local timer to the received 
timestamp value. 

Beacons shall be generated for transmission by the AP once every BeaconPeriod time units. 

11.1.1 .2 TSF for an independent BSS (IBSS) 

The TSF in an IBSS shall be implemented via a distributed algorithm that shall be performed by all of the 
members of the BSS. Each STA in the BSS shall transmit beacons according to the algorithm described in 
this clause. Each STA in an IBSS shall adopt the timing received from any beacon or probe response that has 
a TSF value later than its own TSF timer. 

11.1.2 Maintaining synchronization 

Each STA shall maintain a TSF timer with modulus 2 M counting in increments of microseconds. STAs 
expect to receive beacons at a nominal rate. The interval between beacons is defined by the aBeaconPeriod 
parameter of the STA. A STA sending a beacon shall set the value of the beacon's timestamp so that it equals 
the value of the STA's TSF timer at the time that the first bit of the timestamp is transmitted to the PHY plus 
the transmitting STA's delays through its local PHY from the MAC- PHY interface to its interface with the 
wireless medium (antenna, LED emission surface, etc.). The algorithms in this clause define a mechanism 
that maintains the synchronization of the TSF timers in a BSS to within 4 \is plus the maximum propagation 
delay of the PHY for PHYs of 1 Mbit/s, or greater. 

11.1.2.1 Beacon generation in infrastructure networks 

The AP shall define the timing for the entire BSS by transmitting beacons according to the aBeaconPeriod 
attribute within the A P. This defines a series of TBTTs exactly aBeaconPeriod time units apart. Time zero is 
defined to be a TBTT with the beacon being a DTIM and transmitted at the beginning of a CFP. At each 
TBTT, the AP shall schedule a beacon as the next frame for transmission. If the medium is determined by the 
carrier-sense mechanism (see 9.2. 1 ) to be unavailable, the AP shall delay the actual transmission of a beacon 
according to the basic medium access rules specified in Clause 9. The beacon period is included in Beacon 
and Probe Response frames, and STAs shall adopt that beacon period when joining the BSS. 
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NOTE— Though the transmission of a beacon may be delayed because of CSMA deferrals, subsequent beacons shall be 
scheduled at the nominal beacon interval. This is shown in Figure 64. 

n Beacon Interval 



EL 



: ^ ^ Busy medium ^ 

Other Transmissions 



Beacon Transmissions - 

Figure 64 — Beacon transmission on a busy network 



11.1.2.2 Beacon generation in an IBSS 

Beacon generation in an IBSS is distributed. The beacon period is included in Beacon and Probe Response 
frames, and STAs shall adopt that beacon period when joining the IBSS. All members of the IBSS partici- 
pate in beacon generation. Each STA shall maintain its own TSF timer that is used for aBeaconPeriod 
timing. The beacon interval within an IBSS is established by the STA that instantiates the IBSS. This defines 
a series of TBTTs exactly aBeaconPeriod time units apart. Time zero is defined to be a TBTT. At each TBTT 
the STA shall 

a) Suspend the decrementing of the backoff timer for any pending non-beacon or non-ad hoc traffic indica- 
tion (ATIM) transmission, 

b) Calculate a random delay uniformly distributed in the range between zero and twice aCWmin 
x aSlotTime, 

c) Wait for the period of the random delay, decrementing the random delay timer using the same algo- 
rithm as for backoff, 

d) Cancel the remaining random delay and the pending beacon transmission, if a beacon arrives before 
the random delay timer has expired, and the ATM backoff timer shall resume decrementing. 

e) Send a beacon if the random delay has expired and no beacon has arrived during the delay period. 
(See Figure 65.) 

The beacon transmission shall always occur during the Awake Period of STAs that are operating in a low- 
power mode. This is described in more detail in 1 1 .2. 

11.1.2.3 Beacon reception 

STAs shall use information from the CF Parameter Set element of all received Beacon frames to update their 
NAV as specified in 9.3.2.27 

STAs in an infrastructure network shall only use other information in received Beacon frames, if the BSSID 
field is equal to the MAC address currently in use by the STA contained in the AP of the BSS. 



STAs in an IBSS shall use other information in any received Beacon frame for which the IBSS subfield of 
the Capability field is set to 1 and the content of the SSID element is equal to the SSID of the IBSS. Use of 
this information is specified in 1 1.1.4. 
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Figure 65— Beacon transmission in an IBSS 



11.1 .2.4 TSF timer accuracy 



Upon receiving a Beacon frame with a valid FCS and BSSID or SSID, as described in 1 1 . 1 .2.3, a STA shall 
update its TSF timer according to the following algorithm: The received timestamp value shall be adjusted 
by adding an amount equal to the receiving STA's delay through its local PHY components plus the time 
since the first bit of the timestamp was received at the MAC/PHY interface. In the case of an infrastructure 
BSS, the STA's TSF timer shall then be set to the adjusted value of the timestamp. In the case of an IBSS, the 
STA's TSF timer shall be set to the adjusted value of the received timestamp, if the adjusted value of the 
timestamp is later than the value of the STA's TSF timer. The accuracy of the TSF timer shall be ±0.01%. 



11.1.3 Acquiring synchronization, scanning 

A STA shall operate in either a Passive Scanning mode or an Active Scanning mode depending on the 
current value of the ScanMode parameter of the MLME-SCAN.request primitive. 

Upon receipt of the MLME-SCAN.request primitive, a STA shall perform scanning. The SSID parameter 
indicates the SSID for which to scan. To become a member of a particular ESS using passive scanning, a 
STA shall scan for Beacon frames containing that ESS's SSID, returning all Beacon frames matching the 
desired SSID in the BSSDescriptionSet parameter of the corresponding MLME-SCAN.confirm primitive 
with the appropriate bits in the Capabilities Information field indicating whether the beacon came from an 
Infrastructure BSS or IBSS. To actively scan, the STA shall transmit Probe frames containing the desired 
SSID. Upon completion of scanning, an MLME-SCAN.confirm is issued by the MLME indicating all of the 
BSS information received. 



Upon receipt of an MLME-JOIN.request, the STA will join a BSS by adopting the BSSID, TSF timer value, 
PHY parameters, and the beacon period specified in the request. 



Upon receipt of an MLME-SCAN.request with the broadcast SSID, the STA shall passively scan for any 
Beacon frames, or actively transmit Probe frames containing the broadcast SSID, as appropriate depending 
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upon the value of ScanMode. Upon completion of scanning, an ML ME- SCAN. con firm is issued by the 
MLME indicating all of the BSS information received. 

If a STAs scanning does not result in finding a BSS with the desired SSID and of the desired type, or does 
not result in finding any BSS, the STA may start an IBSS upon receipt of the MLME-START.request. 

A STA may start its own BSS without first scanning for a BSS to join. 

When a STA starts a BSS, that STA shall determine the BSSID of the BSS. If the BSSType indicates an infra- 
structure BSS, then the STA shall start an infrastructure BSS and the BSSID shall be equal to the STAs 
dotl IStationlD. The value of the BSSID shall remain unchanged, even if the value of dotl IStationID is changed 
after the completion of the MLME-Start.request. If the BSSType indicates an IBSS, the STA shall start an IBSS, 
and the BSSID shall be an individual locally administered IEEE MAC address as defined in 5.2 of IEEE Std 
802- 1 990. The remaining 46 bits of that MAC address shall be a number selected in a manner that minimizes the 
probability of STAs generating the same number, even when those STAs are subjected to the same initial condi- 
tions. The value SSID parameter shall be used as the SSID of the new BSS. It is important that designers recog- 
nize the need for statistical independence among the random number streams among STAs. 

11.1.3.1 Passive scanning 

If a ScanType is passive, the STA shall listen to each channel scanned for no longer than a maximum dura- 
tion defined by the ChannelTime parameter. 

11.1.3.2 Active scanning 

Active scanning involves the generation of Probe frames and the subsequent processing of received Probe 
Response frames. The details of the active scanning procedures are as specified in the following subclauses. 

11.1.3.2.1 Sending a probe response 

STAs, subject to criteria below, receiving- Probe Request frames shall respond with a probe response only if 
the SSID in the probe request is the broadcast SSID or matches the specific SSID of the STA. Probe 
Response frames shall be sent as directed frames to the address of the STA that generated the probe request. 
The probe response shall be sent using normal frame transmission rules. An AP shall respond to all probe 
requests meeting the above criteria. In an IBSS, the STA that generated the last beacon shall be the STA that 
responds to a probe request. 

In each BSS there shall be at least one STA that is awake at any given time to respond to probe requests. A 
STA that sent a beacon shall remain in the Awake state and shall respond to probe requests until a Beacon 
frame with the current BSS ID is received. If the STA is an AP, it shall always remain in the Awake state and 
always respond to probe requests. There may be more than one STA in an IBSS that responds to any given 
probe request, particularly in cases where more than one STA transmitted a Beacon frame following the 
most recent TBTT, either due to not receiving successfully a previous beacon or due to collisions between 
beacon transmissions. 

11.1.3.2.2 Active scanning procedure 

Upon receipt of the MLME-SCAN.request with ScanType indicating an active scan, a STA shall use the 
following procedure: 

For each channel to be scanned, 

a) Wait until the ProbeDelay time has expired or a PHYRxStart. indication has been received; 

b) Perform the Basic Access procedure as defined in 9.2.5. 1 ; 
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c) Send a probe with the broadcast destination, SSID, and broadcast BSSID: 

d) Clear and start a ProbeTimer; 

e) If PHYCCA.indication (busy) has not been detected before the ProbeTimer reaches MinChannel- 
Time, then clear NAV and scan the next channel, else when ProbeTimer reaches^MaxChannelTime, 
process all received probe responses; 

0 Clear NAV and scan the next channel. 

See Fiaure 66. 
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Figure 66 — Probe response 



When all channels in the ChannelList have been scanned, the MLME shall issue an MLME-Scan. confirm 
with the BSSDescriptionSet containing all of the information gathered during the scan. 



11.1.3.3 Initializing a BSS 

Upon receipt of an MLME-Start.request, a STA shall determine the BSS's BSSID (as described in 1 1.1.3), 
select channel synchronization information, select a beacon period, initialize and start its TSF timer, and 
begin transmitting beacons. 



11.1.3.4 Synchronizing with a BSS 



Upon receipt of an MLME-Join.request, a STA shall adopt the BSSID, channel synchronization information, 
and TSF timer value of the parameters in the request. Upon receipt of a Beacon frame from the BSS, the 
MLME shall issue an ML ME- Join. confirm indicating the operation was successful. If the JoinFailureTime- 
out expires prior to the receipt of a Beacon frame from the BSS, the MLME shall issue an MLME- 
Join.confirm indicating the operation was unsuccessful. 

1 1 .1 .4 Adjusting STA timers 

In the infrastructure network, STAs shall always adopt the timer in a beacon or probe response coming from 
theAP in their BSS. 



In an IBSS, a STA shall always adopt the information in the contents of a Beacon or Probe Response frame 
when that frame contains a matching SSID and the value of the time stamp is later than the STA's TSF timer. 
In response to an MLME-Join.request, a STA shall initialize its TSF timer to 0 and shall not transmit a 
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beacon or probe response until it hears a beacon or probe response from a member of the IBSS with a match- 
ing SS1D. 

All Beacon and Probe Response frames carry a Timestamp field. A STA receiving such a frame from another 
STA in an IBSS with the same SSID shall compare the Timestamp field with its own TSF time. If the Timestamp 
field of the received frame is later than its own TSF time, the STA shall adopt all parameters contained in the 
Beacon frame. 

11.1.5 Timing synchronization for frequency-hopping (FH) PHYs 

NOTE— This subclause pertains only to STAs using an FH PHY. 

The TSF described here provides a mechanism for STAs in an FH system to synchronize their transitions 
from one channel to another (their "hops"). Every STA shall maintain a table of all of the hopping sequences 
that are used in the system. All of the STAs in a BSS shall use the same hopping sequence. Each beacon and 
probe response includes the channel synchronization information necessary to determine the hop pattern and 
timing for the BSS. , 

STAs shall use their TSF timer to time the aCurrentDwellTime. The aCurrentDwellTime is the length of 
time that STAs shall stay on each frequency in their hopping sequence. Once STAs are synchronized, they 
have the same TSF timer value. 

STAs in the BSS shall issue an appropriate PLME service primitive for the PHY in use to tune to the next 
frequency in the hopping sequence whenever 

TSF timer MOD aCurrentDwellTime = 0 n f 



11.2 Power management 

11.2.1 Power management in an infrastructure network 

STAs changing Power Management mode shall inform the AP of this fact using the Power Management bits 
within the Frame Control field of transmitted frames. The AP shall not arbitrarily transmit MSDUs to STAs 
operating in a power-save (PS) mode, but shall buffer MSDUs and only transmit them at designated times. 

The STAs that currently have buffered MSDUs within the AP are identified in a traffic indication map 
(TIM), which shall be included as an element within all beacons generated by the AP. A STA shall determine 
that an MSDU is buffered for it by receiving and interpreting a TIM. 

STAs operating in PS modes shall periodically listen for beacons, as determined by the STA's Listenlnterval 
and ReceiveDTIMs parameters of the MLME- Power- Mgt. request primitive. 

In a BSS operating under the DCF, or during the contention period of a BSS using the PCF, upon determin- 
ing that an MSDU is currently buffered in the AP, a STA operating in the PS mode shall transmit a short PS- 
Poll frame to the AP, which shall respond with the corresponding buffered MSDU immediately, or acknowl- 
edge the PS-Poll and respond with the corresponding MSDU at a later time. If the TIM indicating the buff- 
ered MSDU is sent during a contention- free period (CFP), a CF-Pollable STA operating in the PS mode does 
not send a PS-Poll frame, but remains active until the buffered MSDU is received (or the CFP ends). If any 
STA in its BSS is in PS mode, the AP shall buffer all broadcast and multicast MSDUs and deliver them to all 
STAs immediately following the next Beacon frame containing a delivery TIM (DTIM) transmission. 
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A STA shall remain in its current Power Management mode until it informs the AP of a Power Management 
mode change via a successful frame exchange. Power Management mode shall not change during any single 
frame exchange sequence, as described in 9.7. 

1 1 .2.1 .1 STA Power Management modes 

A STA may be in one of two different power states: 

— Awake: STA is fully powered. 

— Doze: STA is not able to transmit or receive and consumes very low power. 

The manner in which a STA transitions between these two power states shall be determined by the STAs 
Power Management mode. These modes are summarized in Table 23. 

The Power Management mode of a STA is selected by the PowerManagementMode parameter of the 
MLME-POWERMGT.request. Once the STA updates its Power Management mode, the MLME shall issue 
an MLME-POWERMGT.confirm indicating the success of the operation. 



Table 23 — Power Management modes 



Active mode or AM 


STA may receive frames at any time. In Active mode, a STA shall be in the 
Awake state. A STA on the polling list of a PCF shall be in Active mode for 
the duration of the CFP 


Power Save or PS 


STA listens to selected beacons (based upon the Listenlnterval parameter of the 
MLME-Associate. request primitive) and sends PS- Poll frames to the AP if the 
TIM element in the most recent beacon indicates a directed MSDU buff ered for 
that STA. The AP shall transmit buffered directed MSDUs to a PS STA only in 
response to a PS-Poll from that STA, or during the CFP in the case of a CF-Pol- 
lable PS STA. In PS mode, a STA shaU be in the Doze state and shall enter the 
Awake state to receive selected beacons, to receive broadcast and multicast 
transmissions following certain received beacons, to transmit, and to await 
responses to transmitted PS-Poll frames or (forCF-Pollable STAs) to receive 
contention-free transmissions of buffered MSDUs. 



To change Power Management modes, a STA shall inform the AP through a successful frame exchange initi- 
ated by the STA. The Power Management bit in the Frame Control field of the frame sent by the STA in this 
exchange indicates the Power Management mode that the STA shall adopt upon successful completion of the 
entire frame exchange. 

A STA that is changing from Doze to Awake in order to transmit shall perform clear channel assessment 
(CCA) until a frame sequence is detected by which it can correctly set its NAV, or until a period of time 
equal to the ProbeDelay has transpired. 

1 1 .2.1 .2 AP TIM transmissions 

The TIM shall identify the STAs for which traffic is pending and buffered in the AP. This information is 
coded in a partial virtual bitmap, as described in 7.3.2.6. In addition, the TIM contains an indication whether 
broadcast/multicast traffic is pending. Every STA is assigned an Association ID code (AID) by the AP as 
part of the association process. AID 0 (zero) is reserved to indicate the presence of buffered broadcast/multi- 
cast MSDUs. The AP shall identify those STAs for which it is prepared to deliver buffered MSDUs by 
setting bits in the TIM's partial virtual bitmap that correspond to the appropriate SIDs. 
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11. 2.1. 3 TIM types 

Two different TIM types are distinguished: TIM and DTIM. After a DTIM, the AP shall send out the buff- 
ered broadcast/multicast MSDUs using normal frame transmission rules, before transmitting any unicast 
frames. 



The AP shall transmit a TIM with every beacon. Every DTIMPeriod, a TIM of type "DTIM" is transmitted 
within a beacon, rather than an ordinary TIM. 

i .\ 

Figure 67 illustrates the AP and STA activity under the assumption that a DTIM is transmitted once every 
three TIMs. The top line in Figure 67 represents the time axis, with the beacon interval^shown together with 
a DTIM Interval of three beacon intervals. The second line depicts AP activity. The AP schedules beacons 
for transmission every beacon interval, but the beacons may be delayed if there is traffic'at the TBTT. This is 
indicated as "busy medium" on the second line. For the purposes of this figure, the important fact about 
beacons is that they contain TIMs, some of which may be DTIMs. Note that the second STA with 
Receive DTIMs set to false does not power up its receiver for all DTIMs. 

The third and fourth lines in Figure 67 depict the activity of two STAs operating 'with different power 
management requirements. Both STAs power-on their receivers whenever they need to listen for a TIM. This 
is indicated as a ramp-up of the receiver power prior to the TBTT. The first STA, for example, powers up its 
receiver and receives a TIM in the first beacon; that TIM indicates the presence of a buffered MSDU for the 
receiving STA. The receiving STA then generates a PS-Poll frame, which elicits the transmission of the buff- 
ered data MSDU from the AP. Broadcast and multicast MSDUs are sent by the AP^subsequent to the trans- 
mission of a beacon containing a DTIM. The DTIM is indicated by the DTIM count field of the TIM element 
having a value of 0. ■ , , • 
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Example: DTIM at every 3 TIM intervals 

Figure 67 — Infrastructure power management operation (no PCF operating) 



11.2.1.4 AP operation during the contention period 



APs shall maintain a Power Management status for each currently associated STA that indicates in which 
Power Management mode the STA is currently operating. An AP shall, depending on the Power Manage- 
ment mode of the STA, temporarily buffer the MSDU or management frame destined to the STA. No 
MSDUs or management frames received for STAs operating in the Active mode shall be buffered for power 
management reasons. 
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a) MSDUs, or management frames destined for PS STAs, shall be temporarily buffered in the AP. The 
algorithm to manage this buffering is beyond the scope of this standard. 

b) MSDUs, or management frames destined for STAs in the Active mode, shall be directly transmitted. 

c) At every beacon interval, the AP shall assemble the partial virtual bitmap containing the buffer status 
per destination for STAs in the PS mode, and shall send this out in the TIM field of the beacon. The 
bit for AID 0 (zero) shall be set whenever broadcast or multicast traffic is buffered. 

d) All broadcast/multicast MSDUs, with the Order bit in the Frame Control field clear, shall be buff- 
ered if any associated STAs are in PS mode. 

e) Immediately after every DTIM, the AP shall transmit all buffered broadcast/multicast MSDUs. The 
More Data field of each broadcast/multicast frame shall be set to indicate the presence of further 
buffered broadcast/multicast MSDUs. If the AP is unable to transmit all of the buffered broadcast/ 
multicast MSDUs before the TBTT following the DTIM, the AP shall indicate that it will continue 
to deliver the broadcast/multicast MSDUs by setting the bit for AID 0 (zero) of the TIM element of 
every Beacon frame, until all buffered broadcast/multicast frames have been transmitted. 

f) A single buffered MSDU or management frame for a STA in the PS mode shall be forwarded to the 
STA after a PS-Poll has been received from that STA. The More Data field shall be set to indicate the 
presence of further buffered MSDUs or management frames for the polling STA. Further PS-Poll 
frames from the same STA shall be acknowledged and ignored until the MSDU or management 
frame has either been successfully delivered, or presumed failed due to maximum retries being 
exceeded. This prevents a retried PS-Poll from being treated as a new request to deliver a buffered 
frame. 

g) An AP shall have an aging function to delete pending traffic when it is buffered for an excessive time 
period. 

h) Whenever an AP is informed that a STA changes to the Active mode, then the AP shall send buffered 
MSDUs and management frames (if any exist) to that STA without waiting for a PS-Poll. 

1 1 .2.1 .5 AP operation during the CFP 

APs shall maintain a Power Management status for each currently associated CF-Pollable STA that indicates 
in which Power Management mode the STA is currently operating. An AP shall, for STAs in PS mode, 
temporarily buffer the MSDU destined to the STA. 

a) MSDUs destined for PS STAs shall be temporarily buffered in the AP. The algorithm to manage this 
buffering is beyond the scope of this standard. 

b) MSDUs destined to STAs in the Active mode shall be transmitted as defined in Clause 9. 

c) Prior to every CFP, and at each beacon interval within the CFP, the AP shall assemble the partial 
virtual bitmap containing the buffer status per destination for STAs in the PS mode, set the bits in the 
partial virtual bitmap for STAs the point coordinator (PC) is intending to poll during this CFP, and 
shall send this out in the TIM field of the DTIM. The bit for AID 0 (zero) shall be set whenever 
broadcast or multicast traffic is buffered. 

d) All broadcast and multicast MSDUs, with the Order bit in the Frame Control field clear, shall be 
buffered if any associated STAs are in the PS mode, whether or not those STAs are CF-Pollable. 

e) Immediately after every DTIM (Beacon frame with DTIM Count field of the TIM element equal to 
zero), the AP shall transmit all buffered broadcast and multicast frames. The More Data field shall be 
set to indicate the presence of further buffered broadcast/multicast MSDUs. If the AP is unable to 
transmit all of the buffered broadcast/multicast MSDUs before the TBTT following the DTIM, the 
AP shall indicate that it will continue to deliver the broadcast/multicast MSDUs by setting the bit for 
AID 0 (zero) of the TIM element of every Beacon frame, until all buffered broadcast/multicast 
frames have been transmitted. 

f) Buffered MSDUs or management frames for STAs in the PS mode shall be forwarded to the CF- 
Pollable STAs under control of the PC. Transmission of these buffered MSDUs or management 
frames shall begin immediately after transmission of buffered broadcast and multicast frames (if 
any), and shall occur in order by increasing AID of CF-Pollable STAs. A CF-Pollable STA for which 
the TIM element of the most recent beacon indicated buffered MSDUs or management frames shall 
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be in the Awake state at least until the receipt of a directed frame from the AP in which the Frame 
Control field does not indicate the existence of more buffered MSDUs or management frames. After 
acknowledging the last of the buffered MSDUs or management frames, the CF-Pollable STA operat- 
ing in the PS mode may enter the Doze state until the next DTIM is expected. 

g) An AP shall have an aging function to delete pending traffic buffered for an excessive time period. 
The exact specification of the aging function is beyond the scope of this standard. 

h) Whenever an AP detects that a CF-Pollable STA has changed from the PS mode to the Active mode, 
.then the AP shall queue any buffered frames addressed to that STA for transmission to that CF- 
Pollable STA as directed by the AP's PC function (PCF). 

11.2.1.6 Receive operation for STAs in PS mode during the contention period 

STAs in PS mode shall operate as follows to receive an MSDU or management frame from the AP when no 
PC is operating and during the contention period when a PC is operating. 

a) STAs shall wake up early enough to be able to receive the next scheduled beacon after Listenlntervai 
from the last TBTT. 

b) When a STA detects that the bit corresponding to its AID is set in the TIM, the STA shall issue a PS- 
Poll to retrieve the buffered MSDU or management frame. If more than one bit is set in the TIM, the 
PS-Poll shall be transmitted after a random delay uniformly distributed between zero and aCWmin. 

c) The STA shall remain in the Awake state until it receives the response to its poll, or it receives 
another beacon whose TIM indicates that the AP does not have any MSDUs or management frames 
buffered for this STA. If the bit corresponding to the STAs AID is set in the subsequent TIM, the 
STA shall issue another PS-Poll to retrieve the buffered MSDU or management frame(s). 

d) If the More Data field in the received MSDU or management frame indicates that more traffic for 
that STA is buffered, the STA, at its convenience, shall Poll until no more MSDUs or management 
frames are buffered for that STA. 

e) When ReceiveDTIMs is true, the STA shall wake up early enough to be able to receive every DTIM. 
A STA receiving broadcast/multicast MSDUs shall remain awake until the More Data field of the 
broadcast/multicast MSDUs indicates there are no further buffered broadcast/multicast MSDUs, or 
until a TIM is received indicating there are no more buffered broadcast/multicast MSDUs. 

11.2.1.7 Receive operation for STAs in PS mode during the CFP 

STAs in PS mode that are associated as CF-Pollable shall operate as follows in a BSS with an active PC to 
receive MSDUs or management frames from the AP during the CFP: 

a) STAs shall enter the Awake state so as to receive the Beacon frame (which contains a DTIM) at the 
start of each CFP. 

b) To receive broadcast/multicast MSDUs, the STA shall wake up early enough to be able to receive 
every DTIM that may be sent during the CFP. A STA receiving broadcast/multicast MSDUs shall 
remain awake until the More Data field of the broadcast/multicast MSDUs indicates there are no 
further buffered broadcast/multicast MSDUs, or until a TIM is received indicating there are no more 
broadcast/multicast MSDUs buffered. 

c) When a STA detects that the bit corresponding to its AID is set in the DTIM at the start of the CFP 
(or in a subsequent TIM during the CFP), the STA shall remain in the Awake state for at least that 
portion of the CFP through the time that the STA receives a directed MSDU or management frame 
from the AP with the More Data field in the Frame Control field indicating that no further traffic is 
buffered. 

d) If the More Data field in the Frame Control field of the last MSDU or management frame received 
from the AP indicates that more traffic for the STA is buffered, then, when the CFP ends, the STA 
may remain in the Awake state and transmit PS-Poll frames during the contention period to request 
the delivery of additional buffered MSDU or management frames, or may enter the Doze state 
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during the contention period (except at TBTTs for DTIMs expected during the contention period), 
awaiting the start of the next CFR 

11.2.1.8 STAs operating in the Active mode 

A STA operating in this mode shall have its receiver activated continuously; it does not need to interpret the 
traffic announcement part of the beacons. 

1 1 .2.1 .9 AP aging function 

The AP shall have an aging function to delete buffered traffic when it has been buffered for an excessive 
period of time. That function shall be based on the Listen Interval parameter of the MLME- Assoc iate.request 
primitive of the STA for which the traffic is buffered. The AP aging function shall not cause the buffered traf- 
fic to be discarded after any period that is shorter than the Listenlnterval of the STA for which the traffic is 
buffered. The exact specification of the aging function is beyond the scope of this standard. 

11.2.2 Power management in an IBSS 

This subclause specifies the power management mechanism for use within an IBSS. 
11.2.2.1 Basic approach 

The basic approach is similar to the infrastructure case in that the STAs are synchronized, and multicast 
MSDUs and those MSDUs that are to be transmitted to a power-conserving STA are first announced during 
a period when all STAs are awake. The announcement is done via an ad hoc traffic indication message 
(ATIM). A STA in the PS mode shall listen for these announcements to determine if it needs to remain in the 
awake state. 

When an MSDU is to be transmitted to a destination STA that is in a PS mode, the transmitting STA first 
transmits an ATIM frame during the ATIM Window, in which all the STAs including those operating in a PS 
mode are awake. The ATIM Window is defined as a specific period of time, defined by a ATIM Window, 
following a TBTT, during which only Beacon or ATIM frames shall be transmitted. ATIM transmission 
times are randomized, after a Beacon frame is either transmitted or received by the STA, using the backoff 
procedure with the contention window equal to aCWminx. Directed ATI Ms shall be acknowledged. If a STA 
transmitting a directed ATIM does not receive an acknowledgment, the STA shall execute the backoff proce- 
dure for retransmission of the ATIM. Multicast ATIMs shall not be acknowledged. 

If a STA receives a directed ATIM frame during the ATIM Window, it shall acknowledge the directed ATIM 
and stay awake for the entire beacon interval waiting for the announced MSDU(s) to be received. If a STA 
does not receive an ATIM, it may enter the Doze state at the end of the ATIM Window. Transmissions of 
MSDUs announced by ATIMs are randomized after the ATIM Window, using the backoff procedure 
described in Clause 9. 

It is possible that an ATIM may be received from more than one STA, and that a STA that receives an ATIM 
may receive more, than a single MSDU from the transmitting STA. ATIM frames are only addressed to the 
destination STA of the MSDU. 

An ATIM for a broadcast or multicast MSDU shall have a destination address identical to that of the MSDU. 

After the ATIM interval, only those directed MSDUs that have been successfully announced with an 
acknowledged ATIM, and broadcast/multicast MSDUs that have been announced with an ATIM, shall be 
transmitted to STAs in the PS mode. Transmission of these frames shall be done using the normal DCF 
access procedure. 
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Figure 68 illustrates the basic power-save operation. 
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Figure 68 — Power management in an IBSS — Basic operation 

The estimated power-saving state of another STA may be based on the power management information 
transmitted by that STA and on additional information available locally, such as a history of failed transmis- 
sion attempts. The use of RTS/CTS in an IBSS may reduce the number of transmissions to a STA that is in 
PS mode. If an RTS is sent and a CTS is not received, the transmitting STA may assume that the destination 
STA is in PS mode. The method of estimating the power management state of other STAs in the IBSS is out- 
side the scope of this standard. 



11.2.2.2 Initialization of power management within an IBSS 



The following procedure shall be used to initialize power management within a new IBSS, or to learn about 
the power management being used within an existing IBSS. 

a) A STA joining an* existing IBSS by the procedure in 1 1.1.3.3 shall update its ATIM Window with the 
value contained in the ATIM Window field of the IBSS Parameter Set element within the Beacon or 
Probe Response management frame received during the scan procedure. 

b) A STA creating a new IBSS by the procedure in 1 1.1.3.3 shall set the value of the ATIM Window 
field of the IBSS Parameter Set element within the Beacon management frames transmitted to the 
value of its ATIM Window. 

c) The start of the ATIM Window shall be the TBTT, defined in 11.1 .2.2. The end of the ATIM Window 
shall be defined as 
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TSF timer MOD Beaconlnterval = ATIMWindow. 

d) The ATIM Window period shall be static during the lifetime of the IBSS. 

e) An ATIM Window value of zero shall indicate that power management is not in use within the IBSS. 

11.2.2.3 STA power state transitions 

A STA may enter PS mode if and only if the value of the ATIM Window in use within the IBSS is greater 
than zero. A STA shall set the Power Management subfield in the Frame Control field of MSDUs that it 
transmits according to the procedure in 7.1 .3. 1 .7. 

A STA in PS mode shall transition between Awake and Doze states according to the following rules: 

a) If a STA is operating in PS mode, it shall enter the Awake state prior to each TBTT. 

b) If a STA receives a directed ATIM management frame containing its individual address, or a multi- 
cast ATIM management frame during the ATIM Window it shall remain in the Awake state until the 
end of the next ATIM Window. 

c) If a STA transmits a Beacon or an ATIM management frame, it shall remain in the Awake state until the 
end of the next ATIM Window regardless of whether an acknowledgment is received for the ATIM. 

d) If the STA has not transmitted an ATIM and does not receive either a directed ATIM management 
frame containing its individual address, or a multicast ATIM management frame during the ATIM 
Window, it may return to the Doze state following the end of the current ATIM Window. 

11.2.2.4 ATIM and frame transmission 

If power management is in use within an IBSS, all STAs shall buffer MSDUs for STAs that are known to be 
in PS mode. The algorithm used for the estimation of the power management state of STAs within the IBSS 
is outside the scope of this standard. MSDUs may be sent to STAs in Active mode at any valid time. 

a) Following the reception or transmission of the beacon, during the ATIM Window, the STA shall 
transmit a directed ATIM management frame to each STA for which it has one or more buffered 
unicast MSDUs. If the STA has one or more buffered multicast MSDUs, with the Strictly Ordered 
bit clear, it shall transmit an appropriately addressed multicast ATIM frame. A STA transmitting an 
ATIM management frame shall remain awake for the entire current beacon interval. 

b) All STAs shall use the backoff procedure defined in 9.2.5.2 for transmission of the first ATIM fol- 
lowing the beacon. All remaining ATI Ms shall be transmitted using the conventional DCF access 
procedure. 

c) ATIM management frames shall only be transmitted during the ATIM Window. 

d) A STA shall transmit no frame types other than RTS, CTS, and ACK Control frames and Beacon and 
ATIM management frames during the ATIM Window. 

e) Directed ATIM management frames shall be acknowledged. If no acknowledgment is received, the 
ATIM shall be retransmitted using the conventional DCF access procedure. Multicast ATIM 
management frames shall not be acknowledged. 

f) If a STA is unable to transmit an ATIM during the ATIM Window, for example due to contention 
with other STAs r the. STA shall retain the buffered MSDU(s) and attempt to transmit the ATIM 
during the next ATIM Window. 

g) Immediately following the ATIM Window, a STA shall begin transmission of buffered broadcast/ 
multicast frames for which an ATIM was previously transmitted. Following the transmission of any 
broadcast/multicast frames, any MSDUs and management frames addressed to STAs for which an 
acknowledgment for a previously transmitted ATIM frame was received shall be transmitted. All 
STAs shall use the backoff procedure defined in 9.2.5.2 for transmission of the first frame following 
the ATIM Window. All remaining frames shall be transmitted using the conventional DCF access 
procedure. 
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■ la fr h) A buffered MSDU may be transmitted using fragmentation. If an MSDU has been partially transmit- 

lhc • ted when the next beacon frame is sent, the STA shall retain the buffered MSDU and announce the 

v tnc remaining fragments by transmitting an ATIM during the next ATIM Window. 

i) If an STA is unable to transmit a buffered MSDU during the beacon interval in which it was 
re announced, for example due to contention with other STAs, the STA shall retain the buffered MSDU 

and announce the MSDU again by transmitting an ATIM during the next ATIM Window. 
e lrr ; j) Following the transmission of all buffered MSDUs, a STA may transmit MSDUs without announce- 

ment to STAs that are known to be in the Awake state for the current beacon interval due to an appro- 
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k) A STA may discard frames buffered for later transmission to power-saving STAs if the STA deter- 
mines that the frame has been buffered for an excessive amount of time or if other conditions inter- 
nal to the STA implementation make it desirable to discard buffered frames (for example, buffer 
starvation). In no case shall a frame be discarded that has been buffered for less than aBeaconPeriod. 
The algorithm to manage this buffering is beyond the scope of this standard. 



11.3 Association and reassociation 

::T U:- This subclause defines how a STA associates and reassociates with an AP. 

11.3.1 STA association procedures 

sc Upon receipt of an MLME-ASSOCIATE.request, a STA shall associate with an AP via the following proce- 

dure: 

;now 

' d a) The STA shall transmit an association request to an AP with which that STA is authenticated. 

b) If an Association Response frame is received with a status value of "successful " the STA is now 
associated with the AP and the MLME shall issue an MLME- ASSOC LATE.confirm indicating the 
successful completion of the operation. 

c) If an Association Response frame is received with a status value other than "successful" or the Asso- 
ciateFailureTimeout expires, the STA is not associated with the AP and the MLME shall issue an 

. reef 

MLME-ASSOCIATE. confirm indicating the failure of the operation. 

11.3.2 AP association procedures 

>nse i r 

, 0 f x An AP shall operate as follows in order to support the association of STAs. 
inter 

ie co a ) Whenever an Association Request frame is received from a STA and the STA is authenticated, the 

ecog AP shall transmit an association response with a status code as defined in 7.3. 1 .9. If the status value 

ig tc is "successful," the Association ID assigned to the STA shall be included in the response. If the STA 

:quer is not authenticated, the AP shall transmit a Deauthentication frame to the STA. 

: rec( b) When the association response with a status value of "successful" is acknowledged by the STA, the 

missi STA is considered to be associated with this AP. 

:ess 1 c) The AP shall inform the distribution system (DS) of the association and the MLME shall issue an 

' o11 f MLME-ASSOCIATE'.indication. 

11.3.3 STA reassociation procedures 

Upon receipt of an MLME-REASSOCIATE.request, a STA shall reassociate with an AP via the following 
or PO) procedure: 
ticatt 

a) The STA shall transmit a Reassociation Request frame to an AP. 
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b) If a Reassociation Response frame is received with a status value of "successful," the STA is now 
associated with the AP and the MLME shall issue an MLME- RE ASSOC I ATE. con firm indicating 
the successful completion of the operation. 

c) If a Reassociation Response frame is received with a status value other than "successful" or the 
ReassociateFailureTimeout expires, the STA is not associated with the AP and the MLME shall 
issue an MLME-REASSOCIATE.ccnfirm indicating the failure of the operation. 

1 1 .3.4 AP reassociation procedures 

An AP shall operate as follows in order to support the reassociation of STAs. 

a) Whenever a Reassociation Request frame is received from a STA and the STA is authenticated, the 
AP shall transmit a reassociation response with a status value as defined in 7.3. 1 .9. If the status value 
is "successful," the Association ID assigned to the STA shall be included in the response. If the STA 
is not authenticated, the AP shall transmit a Deauthentication frame to the STA. 

b) When the reassociation response with a status value of "successful" is acknowledged by the STA, 
the STA is considered to be associated with this AP. 

c) The AP shall inform the DS of the reassociation and the MLME shall issue an MLME- 
REASSOCIATE.indication. 

11.4 Management information base (MIB) definitions 

The MIB comprises the managed objects, attributes, actions, and notifications required to manage a station. 
The definition of these managed objects, attributes, actions, and notifications, as well as their structure, is 
presented in Annex D. 
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12. Physical layer (PHY) service specification 

12.1 Scope 

The PHY services provided to the IEEE 802. 1 1 wireless LAN MAC are described in this clause. Different 
PHYs are defined as part of the IEEE 802!l I standard. Each PHY can consist of two protocol functions as 
follows: 

a) A physical layer convergence function, which adapts the capabilities of the physical medium depen- 
dent (PMD) system to the PHY service. This function is supported by the physical layer conver- 
gence procedure (PLCP), which defines a method of mapping the IEEE 802. 1 1 MAC sublayer 
protocol data units (MPDUs) into a framing format suitable for sending and receiving user data and 
management information between two or more STAs using the associated PMD system. 

b) A PMD system, whose function defines the characteristics of, and method of transmitting and 
receiving data through, a wireless medium (WM) between two or more STAs. 

Each PMD sublayer may require the definition of a unique PLCP. If the PMD sublayer already provides the 
defined PHY services, the physical layer convergence function might be null. 

12.2 PHY functions 

The protocol reference model for the IEEE 802. 1 1 architecture is shown in Figure 1 1. Most PHY definitions 
contain three functional entities: the PMD function, the physical layer convergence function, and the layer 
management function. 

The PHY service is provided to the MAC entity at the STA through a service access point (SAP), called the 
PHY-SAP, as shown in Figure 1 1 . A set of primitives might also be defined to describe the interface between 
the physical layer convergence protocol sublayer and the PMD sublayer, called the PMD- SAP. 

12.3 Detailed PHY service specifications 

12.3.1 Scope and field of application 

The services provided by the PHY to the IEEE 802.1 1 MAC are specified in this subclause. These services are 
described in an abstract way and do not imply any particular implementation or exposed interface. 

12.3.2 Overview of the service 

The PHY function as shown in Figure 1 1 is separated into two sublayers: the PLCP sublayer and the PMD 
sublayer. The function of the PLCP sublayer is to provide a mechanism for transferring MPDUs between 
two or more STAs over the PMD sublayer. 

12.3.3 Overview of interactions 

The primitives associated with communication between the IEEE 802. II MAC sublayer and the IEEE 
802. 1 1 PHY fall into two basic categories: 

a) Service primitives that support MAC peer-to-peer interactions; 

b) Service primitives that have local significance and support sublayer-to-sublayer interactions. 
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12.3.4 Basic service and options 

All of the service primitives described here are considered mandatory unless otherwise specified. 
12.3.4.1 PHY-SAP peer-to-peer service primitives 

Table 24 indicates the primitives for peer-to-peer interactions. 



Table 24 — PHY-SAP peer-to-peer service primitives 



Primitive 


Request 


Indicate 


Confirm 


PHY-DATA 


X 


X 


X 



12.3.4.2 PHY-SAP sublayer-to-sublayer service primitives 

Table 25 indicates the primitives for sublayer-to-sublayer interactions. 



Table 25 — PHY-SAP sublayer-to-sublayer service primitives 



Primitive 


Request 


Indicate 


Confirm 


PHY-TXSTART 


X 




X 


PHY-TXEND 


X 




X 


PHY-CCARESET 


X 




X 


PHY-CCA 




X 




PHY-RXSTART 




X 




PHY-RXEND 




X 





12.3.4.3 PHY-SAP service primitives parameters 

Table 26 shows the parameters used by one or more of the PHY-SAP service primitives. 



Table 26 — PHY-SAP service primitive parameters 



Parameter 


Associated primitive 


Value 


DATA 


PHY- DATA. request 
PHY-DATA.indication 


Octet value XW-X'FF 


TXVECTOR 


P H Y-TXSTA RT. req ues t 


A set of parameters 


STATUS 


PHY-CCA.indication 


BUSY, IDLE 


RX VECTOR 


PHY-RXSTART.indication 


A set of parameters 


RXERROR 


PHY-RXEND.indication 


No Error, Format Violation, Carrier- 
Lost, UnsupportedRate 
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12.3.4.4 Vector descriptions 

Several service primitives include a parameter vector. This vector is a list of parameters that may vary 
depending on the PHY type. Table 27 lists the parameter values required by the MAC or PHY in each of the 
parameter vectors. Parameters in the vectors that are management rather than MAC may be specific to the 
PHY and are listed in the clause covering that PHY. 



Table 27 — Vector descriptions 



Parameter 


Associate vector 


Value 


DATARATE 


TXVECTOR, RXVECTOR 


PHY dependent. The name of the 
field used to specify the Tx data rate 
and report the Rx data rate may vary 
for different PHYs. 


LENGTH 


TXVECTOR, RXVECTOR 


PHY dependent 



12.3.5 PHY-SAP detailed service specification 

The following subclause describes the services provided by each PHY sublayer primitive. 

12.3.5.1 PHY-DATA.request 

12.3.5.1.1 Function 

This primitive defines the transfer of an octet of data from the MAC sublayer to the local PHY entity. 

12.3.5.1.2 Semantics of the service primitive 
The primitive provides the following parameters: 

PHY-DATA.request (DATA) 
The DATA parameter is an octet of value X'00' through X'FF. 

12.3.5.1.3 When generated 

This primitive is generated by the MAC sublayer to transfer an octet of data to the PHY entity. This primitive 
can only be issued following a transmit initialization response (PHY-TXSTART.confirm) from the PHY 
layer. 

12.3.5.1.4 Effect of receipt 

The receipt of this primitive by the PHY entity causes the PLCP transmit state machine to transmit an octet 
of data. When the PHY entity receives the octet, it will issue a PHY-DATA.confirrn to the MAC sublayer. 

12.3.5.2 PHY-DATA.indication 
12.3.5.2.1 Function 

This primitive indicates the transfer of data from the PHY sublayer to the local MAC entity. 
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12.3.5.2.2 Semantics of the s rvice primitive 

The primitive provides the following parameters: 

PHY-DATA.indication (DATA) 
The DATA parameter is an octet of value X'00' through X'FF'. 

12.3.5.2.3 When generated 

The PHY-DATA.indication is generated by a receiving PHY entity to transfer the received octet of data to the 
local MAC entity. The time between receipt of the last bit of the provided octet from the wireless medium 
and the receipt of this primitive by the MAC entity will be the sum of aRXRFDelay + aRxPLCPDelay. 

12.3.5.2.4 Effect of receipt 

The effect of receipt of this primitive by the MAC is unspecified. 

12.3.5.3 PHY-DATA.confirm 

12.3.5.3.1 Function 

This primitive is issued by the PHY sublayer to the local MAC entity to confirm the transfer of data from the 
MAC entity to the PHY sublayer. 

12.3.5.3.2 Semantics of the service primitive 

The semantics of the primitive are as follows: 

PHY-DATA.confirm 
This primitive has no parameters. 

12.3.5.3.3 When generated 

This primitive will be issued by the PHY sublayer to the MAC entity whenever the PLCP has completed the 
transfer of data from the MAC entity to the PHY sublayer. The PHY sublayer will issue this primitive in 
response to every PHY- DATA. request primitive issued by the MAC sublayer. 

12.3.5.3.4 Effect of receipt 

The receipt of this primitive by the MAC will cause the MAC to start the next MAC entity request. 

12.3.5.4 PHY-TXSTART.request 
12.3.5.4.1 Function 

This primitive is a request by the MAC sublayer to the local PHY entity to start the transmission of an 
MPDU. 
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12.3.5.4.2 Semantics of the service primitive 

The primitive provides the following parameters: 

PHY-TX START, request (TXVECTOR) 

The TXVECTOR represents a list of parameters that the MAC sublayer provides to the local PHY entity in 
order to transmit an MPDU. This vector contains both PLCP and PHY management parameters. The 
required PHY parameters are listed in 1 2.3.4.4. 

12.3.5.4.3 When generated 

This primitive will be issued by the MAC sublayer to the PHY entity whenever the MAC sublayer needs to 
begin the transmission of an MPDU. 

12.3.5.4.4 Effect of receipt 

The effect of receipt of this primitive by the PHY entity will be to start the local transmit state machine. 

12.3.5.5 PHY-TXSTART.confirm 

12.3.5.5.1 Function 

This primitive is issued by the PHY sublayer to the local MAC entity to confirm the start of a transmission. 
The PHY sublayer will issue this primitive in response to every PHY-TXSTART.request primitive issued by 
the MAC sublayer. 

12.3.5.5.2 Semantics of the service primitive 

The semantics of the primitive are as follows: 

PHY-TXSTART.confirm 
There are no parameters associated with this primitive. 

12.3.5.5.3 When generated 

This primitive will be issued by the PHY sublayer to the MAC entity whenever the PHY has received a 
PHY-TXSTART.request from the MAC entity and is ready to begin receiving data octets. 

12.3.5.5.4 Effect of receipt 

The receipt of this primitive~by the MAC entity will cause the MAC to start the transfer of data octets. 

12.3.5.6 PHY-TXEND.request 
12.3.5.6.1 Function 

This primitive is a request by the MAC sublayer to the local PHY entity that the current transmission of the 
MPDU be completed. 



1 42 



Copyright © 1999 IEEE. All rights reserved. 



ISO/IEC 8802-11: 1999(E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.11, 1999 Edition 

12.3.5.6.2 Semantics of the service primitive 

The semantics of the primitive are as follows: 

PHY-TXEND.request 
There are no parameters associated with this primitive. 

12.3.5.6.3 When generated 

This primitive wii! be generated whenever the MAC sublayer has received the last PHY- DATA. con firm from 
the local PHY entity for the MPDU currently being transferred. 

12.3.5.6.4 Effect of receipt 

The effect of receipt of this primitive by the local PHY entity will be to stop the transmit state machine. 

12.3.5.7 PHY-TXEND.confirm 

12.3.5.7.1 Function 

This primitive is issued by the PHY sublayer to the local MAC entity to confirm the completion of a trans- 
mission. The PHY sublayer issues this primitive in response to every PHY-TXEND.request primitive issued 
by the MAC sublayer. 

12.3.5.7.2 Semantics of the service primitive 

The semantics of the primitive are as follows: 

PHY-TXEND.confirm 
There are no parameters associated with this primitive. 

12.3.5.7.3 When generated 

This primitive will be issued by the PHY sublayer to the MAC entity whenever the PHY has received a 
PHY-TXEND.request immediately after transmitting the end of the last bit of the last data octet indicating 
that the last data octet has been transferred. 

12.3.5.7.4 Effect of receipt 

The receipt of this-primitive-by the MAC entity provides the time reference for the contention backoff protocol. 

12.3.5.8 PHY-CCARESET.request 
12.3.5.8.1 Function 

This primitive is a request by the MAC sublayer to the local PHY entity to reset the clear channel assessment 
(CCA) state machine. 
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12.3.5.8.2 Semantics of the service primitive 

The semantics of the primitives are as follows: 

PHY-CCARESET.request 
There are no parameters associated with this primitive. 

1 2.3.5.8.3 When generated 

This primitive is generated by the MAC sublayer for the local PHY entity at the end of a NAV timer This 
request can be used by some PHY implementations that may synchronize antenna diversity with slot timings. 

12.3.5.8.4 Effect of receipt 

The effect of receipt of this primitive by the PHY entity is to reset the PLCP CS/CCA assessment timers to 
the state appropriate for the end of a received frame. 

12.3.5.9 PHY-CCARESET.confirm 

12.3.5.9.1 Function 

This primitive is issued by the PHY sublayer to the local MAC entity to confirm that the PHY has reset the 
CCA state machine. 

12.3.5.9.2 Semantics of the service primitive 

The semantics of the primitives are as follows: 

PHY-CCARESET.request 
There are no parameters associated with this primitive. 

12.3.5.9.3 When generated 

This primitive is issued by the PHY sublayer to the MAC entity whenever the PHY has received a PHY- 
CCARESET.request. 

12.3.5.9.4 Effect of receipt 

The effect of receipt of this primitive by the MAC is unspecified. 

12.3.5.10 PHY-CCA.indication 

12.3.5.10.1 Function 

This primitive is an indication by the PHY sublayer to the local MAC entity of the current state of the 
medium. 

12.3.5.10.2 Semantics of the service primitive 

The primitive provides the following parameter: 
PHY-CCA.indication (STATE) 
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The STATE parameter can be one of two values: BUSY or IDLE. The parameter value is BUSY if the chan- 
nel assessment by the PHY sublayer determines that the channel is not available. Otherwise, the value of the 
parameter is IDLE. 

12.3.5.10.3 When generated 

This primitive is generated every time the status of the channel changes from channel idle to channel busy or 
from channel busy to channel idle. This includes the period of time when the PHY sublayer is receiving data. 
The PHY sublayer maintains the channel busy indication until the period indicated by the length field in a 
valid PLCP Header has expired. 

12.3.5.10.4 Effect of receipt 

The effect of receipt of this primitive by the MAC is unspecified. 

12.3.5.11 PHY-RXSTART.indication 

12.3.5.11.1 Function 

This primitive is an indication by the PHY sublayer to the local MAC entity that the PLCP has received a 
valid start frame delimiter (SFD) and PLCP Header. 

1 2.3.5.1 1 .2 Semantics of the service primitive 

The primitive provides the following parameter: 

PHY-RXSTART.indication (RXVECTOR) 

The RXVECTOR represents a list of parameters that the PHY sublayer provides the local MAC entity upon 
receipt of a valid PLCP Header. This vector may contain both MAC and MAC management parameters. The 
required parameters are listed in 12.3.4.4. 

12.3.5.11.3 When generated 

This primitive is generated by the local PHY entity to the MAC sublayer whenever the PHY has successfully 
validated the PLCP Header error check CRC at the start of a new PLCP PDU. 

12.3.5.11.4 Effect of receipt 

The effect of receipt of this primitive by the MAC is unspecified. 

12.3.5.12 PHY-RXEND.indication 

12.3.5.12.1 Function 

This primitive is an indication by the PHY sublayer to the local MAC entity that the MPDU currently being 
received is complete. 

12.3.5.12.2 Semantics of the service primitive 

The primitive provides the following parameter: 
PHY-RXEND.indication (RXERROR) 
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The RXERROR parameter can convey one or more of the following values: NoError, Format Violation, Car- 
rierLost, or UnsupportedRate. A number of error conditions may occur after the PLCPs receive state 
machine has detected what appears to be a valid preamble and SFD. The following describes the parameter 
returned for each of those error conditions. 

— NoError. This value is used to indicate that no error occurred during the receive process in the PLCR 

— FormatViolation. This value is used to indicate that the format of the received PLCPPDU was in 
error. 

— CarrierLost This value is used to indicate that during the reception of the incoming MPDU, the 
carrier was lost and no further processing of the MPDU can be accomplished. 

— UnsupportedRate. This value is used to indicate that during the reception of the incoming PLCP- 
PDU, a nonsupported date rate was detected. 

12.3.5.12.3 When generated 

This primitive is generated by the PHY sublayer for the local MAC entity to indicate that the receive state 
machine has completed a reception with or without errors. 

12.3.5.12.4 Effect of receipt 

The effect of receipt of this primitive by the MAC is unspecified. 
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13. PHY management 

The MIB comprises the managed objects, attributes, actions, and notifications required to manage a station. 
The definition of these managed objects, attributes, actions, and notifications, as well as their structure, is 
presented in Annex D. 
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14. Frequency-Hopping spread spectrum (FHSS) PHY specification for the 
2.4 GHz Industrial, Scientific, and Medical (ISM) band 

14.1 Overview 

14.1.1 Overview of FHSS PHY 

The PHY services provided to the IEEE 802.11 wireless LAN MAC for the 2.4 GHz frequency- hopping 
spread spectrum (FHSS) system are described in this clause. The FHSS PHY consists of the following two 
protocol functions: 

a) A physical layer convergence function which adapts the capabilities of the physical medium depen- 
dent (PMD) system to the PHY service. This function is supported by the physical layer conver- 
gence procedure (PLCP), which defines a method of mapping the IEEE 802.11 MAC sublayer 
protocol data units (MPDUs) into a framing format suitable for sending and receiving user data and 
management information between two or more STAs using the associated PMD system. 

b) A PMD system, whose function defines the characteristics of, and method of transmitting and 
receiving data through, a wireless medium (WM) between two or more STAs. 

14.1.2 FHSS PHY functions 

The 2.4 GHz FHSS PHY architecture is shown in Figure 1 1. The FHSS PHY contains three functional enti- 
ties: the PMD function, the physical layer convergence function, and the physical layer management func- 
tion. Each of these functions is described in detail in the following subclauses. 

The FHSS PHY service is provided to the MAC entity at the STA through a PHY service access point (SAP) 
called the PHY-SAP, as shown in Figure 1 1 . A set of primitives might also be defined that describe the inter- 
face between the physical layer convergence protocol sublayer and the PMD sublayer, called the PMD- SAP. 

14.1.2.1 PLCP sublayer 

To allow the IEEE 802. 1 1 MAC to operate with minimum dependence on the PMD sublayer, a PHY conver- 
gence sublayer is defined. This function simplifies provision of a PHY service interface to the IEEE 802. 1 1 
MAC services. 

14.1.2.2 Physical layer management entity (PLME) 

The PLME performs management of the local PHY functions in conjunction with the MAC management 
entity. 

14.1.2.3 PMD sublayer 

The PMD sublayer provides a transmission interface used to send and receive data between two or more 
STAs. . 

14.1.3 Service specification method and notation 

The models represented by state diagrams in the following subclauses are intended as the primary specifica- 
tions of the functions provided. It is important to distinguish, however, between a model and a real imple- 
mentation. The models are optimized for simplicity and clarity of presentation, while any realistic 
implementation may place heavier emphasis on efficiency and suitability to a particular implementation 
technology. 
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The service of a layer or sublayer is the set of capabilities that it offers to a user in the next higher layer (or 
sublayer). Abstract services are specified here by describing the service primitives and parameters that char- 
acterize each service. This definition of service is independent of any particular implementation. 

14.2 FHSS PHY-specific service parameter lists 

14.2.1 Overview 

The architecture of the IEEE 802.1 1 MAC is intended to be PHY independent. Some PHY implementations 
require medium management state machines running in the MAC sublayer in order to meet certain PMD 
requirements. These PHY-dependent MAC state machines reside in a sublayer defined as the MAC sublayer 
management entity (MLME). The MLME in certain PMD implementations may need to interact with the phys- 
ical layer management entity (PLME) as part of the normal PHY- SAP primitives. These interactions are 
defined by the PLME parameter list currently defined in the PHY Service Primitives as TXVECTOR and 
RXVECTOR. The list of these parameters and the values they may represent are defined in the specific PHY 
specifications for each PMD. This subclause addresses the TXVECTOR and RXVECTOR for the FHSS PHY 

All of the values included in the TXVECTOR or RXVECTOR described in this subclause are considered 
mandatory unless otherwise specified. The 1 Mbit's and 2 Mbit/s data rates are the only rates currently sup- 
ported. Other indicated data rates are for possible future use. * 

14.2.2 TXVECTOR parameters 

The parameters in Table 28 are defined as part of the TXVECTOR parameter list in the 
PHY-TXSTART.request service primitive. 



Table 28— TXVECTOR parameters 



Parameter 


Associate primitive 


Value 


LENGTH 


PHY-TXSTART.request (TXVECTOR) 


I -4095 


DATARATE 


PHY-TXSTART.request (TXVECTOR) 


l, 1.5, 2, 2.5, 3,3.5, 4,4.5 



14.2.2.1 TXVECTOR LENGTH 

The LENGTH parameter has the value of I to 4095. This parameter is used to indicate the number of octets 
in the MPDU thaj the MAC. is currently requesting the PHY to transmit. This value is used by the PHY to 
determine the number of octet transfers that will occur between the MAC and the PHY after receiving a 
request to start a transmission. 

14.2.2.2 TXVECTOR DATARATE 

The DATARATE parameter describes the bit rate at which the PLCP should transmit the PSDU. Its value can 
be any of the rates as defined in Table 28, and supported by the conformant FH PHY 
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14.2.3 RXVECTOR parameters 

The parameters in Table 29 are defined as part of the RXVECTOR parameter list in the 
PHY-RXSTART. indicate service primitive. 



Table 29— RXVECTOR parameters 



Parameter 


Associate primitive 


Value 


LENGTH 


PHY-RXSTART.indicate (RXVECTOR) 


1-4095 


RSSI 


PHY-RXSTART indicate (RXVECTOR) 


0-RSSI Max 


DATARATE 


PHY-RXSTART. request (RXVECTOR) 


I, 1.5, 2, 2.5,3,3.5, 4,4.5 



14.2.3.1 TRXVECTOR LENGTH 

The LENGTH parameter has the value of 1 to 4095. This parameter is used to indicate the value contained in 
the LENGTH field that the PLCP has received in the PLCP Header. The MAC and PLCP will use this value 
to determine the number of octet transfers that will occur between the two sublayers during the transfer of 
the received PSDU. 

14.2.3.2 RXVECTOR RSSI 

The receive signal strength indicator (RSSI) is an optional parameter that has a value of 0 through RSSI 
Max. This parameter is a measure by the PHY sublayer of the energy observed at the antenna used to receive 
the current PPDU. RSSI shall be measured between the beginning of the start frame delimiter (SFD) and the 
end of the PLCP header error check (HEC). RSSI is intended to be used in a relative manner. Absolute accu- 
racy of the RSSI reading is not specified. 

14.3 FHSS PLCP sublayer 
14.3.1 Overview 

This subclause provides a convergence procedure to map MPDUs into a frame format designed for FHSS 
radio transceivers. The procedures for transmission, carrier sense, and reception are defined for single and 
multiple antenna diversity radios. 

14.3.1.1 State diagram notation 

The operation of the procedures can be described by state diagrams. Each diagram represents the domain 
and consists of a group of connected, mutually exclusive states. Only one state is active at any given time. 
Each state is represented by a rectangle as shown in Figure 69. These are divided into two parts by a horizon- 
tal line. In the upper part the state is identified by a name. The lower part contains the name of any signal that 
is generated. Actions described by short phrases are enclosed in brackets. 

Each permissible transition between the states is represented graphically by an arrow from the initial to the 
terminal state. A transition that is global in nature (for example, an exit condition from all states to the IDLE 
or RESET state) is indicated by an open arrow. Labels on transitions are qualifiers that must be fulfilled 
before the transition will be taken. The label UCT designates an unconditional transition. Qualifiers 
described by short phrases are enclosed in parentheses. 
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Terms to 


<State Name> 


Terms to 




enter state 


<Message Sent> 


exit state 




< ... > (condition) 






[Actions taken] 





Key: () = condition, for example, (if no_collision) 

( ] = action, for example, [resetPLSfunctions] 

= logical AND 

+ = logical OR 

U CT = unconditional transition 

Figure 69— State diagram notation example 

State transitions and sending and receiving of messages occur instantaneously. When a state is entered and 
the condition to leave that state is not immediately fulfilled, the state executes continuously, sending the 
messages and executing the actions contained in the state in a continuous manner. 

Some devices described in this standard are allowed to have two or more ports. State diagrams capable of 
describing the operation of devices with an unspecified number of ports require qualifier notation that allows 
testing for conditions at multiple ports. The notation used is a term that includes a description in parentheses 
of which ports must meet the term for the qualifier to be satisfied (e.g., ANY and ALL). It is also necessary 
to provide for term-assignment statements that assign a name to a port that satisfies a qualifier. The following 
convention is used to describe a term-assignment statement that is associated with a transition: 

a) The character "f * (colon) is a delimiter used to denote that a term assignment statement follows. 

b) The character (left arrow) denotes assignment of the value following the arrow to the term 
preceding the arrow. 

The state diagrams contain the authoritative statement of the procedures they depict; when apparent conflicts 
between descriptive text and state diagrams arise, the state diagrams are to take precedence. This does not, 
however, override any explicit description in the text that has no parallel in the state diagrams. 

The models presented by state diagrams are intended as the primary specifications to be provided. It is 
important to distinguish, however, between a model and a real implementation. The models are optimized 
for simplicity and clarity of presentation, while any realistic implementation may place heavier emphasis on 
efficiency and suitability to a particular implementation technology. It is the functional behavior of any unit 
that must match the standard, not its internal structure. The internal details of the model are useful only to 
the extent that they specify the external behavior clearly and precisely. 

14.3.2 PLCP frame format 

The PLCP protocol data unit (PPDU) frame format provides for the asynchronous transfer of MAC sublayer 
MPDUs from any transmitting STA to all receiving STAs within the wireless LAN's BSS. The PPDU illus- 
trated in Figure 70 consists of three pans: a PLCP Preamble, a PLCP Header, and a PSDU. The PLCP 
Preamble provides a period of time for several receiver functions. These functions include antenna diversity, 
clock and data recovery, and field delineation of the PLCP Header and the PSDU. The PLCP Header is used 
to specify the length of the whitened PSDU field and support any PLCP management information. The 
PPDU contains the PLCP Preamble, the PLCP Header, and the PSDU modified by the PPDU data whitener. 



Copyright © 1999 IEEE. All rights reserved. 



151 



ISO/IEC 8802-11: 1999(E) 
ANSI/IEEE Std 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



PLCP Preamble 


PLCP Header 




Sync 


Start Frame 
Delimiter 


PLW 


PSF 


Header Er- 
ror Check 


Whitened PSDU 


80 bits 


16 bits 12 bits 4 bits 


16 bits 


Variable number of octets 



Figure 70— PLCP frame format 



14.3.2.1 PLCP Preamble 

The PLCP Preamble contains two separate subfields; the Preamble Synchronization (SYNC) field and the 
Start Frame Delimiter (SFD), to allow the PHY circuitry to reach steady-state demodulation and synchroni- 
zation of bit clock and frame start. 

14.3.2.1.1 Preamble SYNC field 

The Preamble SYNC field is an 80-bit field containing an alternating zero-one pattern, transmitted starting 
with zero and ending with one, to be used by the PHY sublayer to detect a potentially receivable signal, 
select an antenna if diversity is utilized, and reach steady -state frequency offset correction and synchroniza- 
tion with the received packet timing. 

14.3.2.1.2 Start Frame Delimiter (SFD) 

The SFD consists of the 16-bit binary pattern 0000 1 100 101 1 1 101 (transmitted leftmost bit first). The first 
bit of the SFD follows the last bit of the sync pattern. The SFD defines the frame timing. 

14.3.2.2 PLCP Header field 

The PLCP Header field contains three separate subfields: a 1 2-bit PSDU Length Word (PLW), a 4-bit PLCP 
Signaling field (PSF), and a 16-bit PLCP HEC field. 

14.3.2.2.1 PSDU length word 

The PSDU length word (PLW) is passed from the MAC as a parameter within the P H Y-TX STA RT. request 
primitive. The PLW specifies the number of octets contained in the PSDU. Its valid values are X'OOT- 
X'FFF, representing counts of one to 4095 octets. The PLW is transmitted lsb first and msb last. The PLW is 
used by the receiving STA, in combination with the 32/33 coding algorithm specified in this clause, to deter- 
mine the last bit in the packet. 



152 



Copyright © 1999 IEEE. All rights reserved. 



' ISO/IEC 8802-11: 1999(E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.11, 1999 Edition 

14.3.2.2.2 PLCP Signaling field (PSF) 

The 4-bit PSF is defined in Table 30. The PSF is transmitted bit 0 first and bit 3 last. 



Table 30 — PSF bit descriptions 



Bit 


Parameter name 


Parameter values 


Description 


0 


Reserved 


Default = 0 


Reserved 


1:3 


PLCPJ3ITRATE 


hi hi hi 


= Data Rate 


This field indicates the data rate of the 






0 0 0 


= 1 .0 Mbit/s, 


whitened PSDU from 1 Mbit/s to 






0 0 I 


= 1.5 Mbit/s, 


4.5 Mbit/s in 0.5 Mbit/s increments. 






0 1 0 


= 2.0 Mbit/s, 








0 1 1 


= 2.5 Mbit/s, 








I 0 0 


= 3.0 Mbit/s, 








1 0 1 


= 3.5 Mbit/s, 








1 I 0 


= 4.0 Mbit/s, 








I I 1 


= 4.5 Mbit/s 





14.3.2.2.3 Header Error Check (HEC) field 

The HEC field is a 16-bit CCITT CRC- 16 error detection field. The HEC uses the CCITT CRC-16 generator 
polynomial G(x) as follows: 

G(x)=x ]6 +x l2 +x 5 +\ 
The HEC shall be the one's complement of the sum (modulo 2) of the following: 

a) The remainder of x (x 15 + x 14 + ... + x 2 + jc 1 +1) divided (modulo 2) by G(x) y where k is the 
number of bits in the PSF and PLW fields of the PLCP Header; 

b) The remainder after multiplication by jc 16 and then division (modulo 2) by G(x) of the content 
(treated as a polynomial) of the PSF and PLW fields. 

The HEC shall be transmitted with the coefficient of the highest term first. 

As a typical implementation, at the transmitter, the initial remainder of the division is preset to all ones and 
is then modified by division of the PSF and PLW fields by the generator polynomial, G(x). The one's 
complement of this remainder is inserted in the HEC field with the msb transmitted first. 

At the receiver, the initial remainder of the division is again preset to all ones. The division of the received 
PSF, PLW, and HEC fields by the generator polynomial, G(x), results, in the absence of transmission errors, 
in a unique nonzero value, which is the following polynomial R(x)\ 

R(x) = x l2 + x n + x [0 + x* + x* + x 2 + x l + I 
14.3.2.3 PLCP data whitener 

The PLCP data whitener uses a length- 127 frame-synchronous scrambler followed by a 32/33 bias-suppres- 
sion encoding to randomize the data and to minimize the data dc bias and maximum run lengths. Data octets 
are placed in the transmit serial bit stream Isb first and msb last. The frame synchronous scrambler uses the 
generator polynomial S(x) as follows: 
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and is illustrated in Figure 71. The 127-bit sequence generated repeatedly by the scrambler is (leftmost bit 
used first) 00001110 11110010 11001001 00000010 00100110 00101110 101 101 10 00001 100 1 1010100 
II 1001 II 10110100 00101010 11111010 01010001 101 11000 111 1111. The same scrambler is used to 
scramble transmit data and to descramble receive data. The data whitening starts with the first bit of the 
PSDU, which follows the last bit of the PLCP Header. The specific bias suppression encoding and decoding 
method used is defined in Figure 75 and Figure 80. The format of the packet after data whitening is as shown 
in Figure 72, 




Initialize all registers with ones ▼ 

(De-)Scrambled 
Data out 

Figure 71— Frame synchronous scrambler/descrambler 



PPDU 



^ 












p> 


( Preamble 1 f 52-symbol block ^ 




Sync 


SFD 


PLCP Header ■ 












1 



Stuff symbol Stuff symbol Stuff symbol 

Data Octet 



Figure 72— PLCP data whitener format 



14.3.3 PLCP state machines 

The PLCP consists of three state machines, as illustrated in the overview diagram of Figure 73: the transmit 
(TX), carrier sense/clear channel assessment (CS/CCA), and receive (RX) state machines. The three PLCP 
state machines are defined in the subclauses below; Figure 73 is not a state diagram itself. Execution of the 
PLCP state machines normally is initiated by the FH PLME state machine and begins at the CS/CCA state 
machine. The PLCP returns to the FH PLME state machine upon interrupt to service a PLME service 
request, such as PLME-SET, PLME-RESET, etc. 

14.3.3.1 PLCP transmit procedure 

The PLCP transmit procedure is invoked by the CS/CCA procedure immediately upon receiving a 
PHY-TXSTART.request(TXVECTOR) from the MAC sublayer. The CSMA/CA protocol is performecfby 
the MAC with the. PHY PLCP in the CS/CCA procedure prior to executing the transmit procedure. 

14.3.3.1.1 Transmit state machine 

The PLCP transmit state machine illustrated in Figure 74 includes functions that must be performed prior to, 
during, and after PPDU data transmission. Upon entering the transmit procedure in response to a 
PHY-TXSTART.request (TXVECTOR) from the MAC, the PLCP shall switch the PHY PMD circuitry from 
receive to transmit state; ramp on the transmit power amplifier in the manner prescribed in 1 4.6; and transmit 
the preamble sync pattern and SFD. The PLCP shall generate the PLCP Header as defined in 1 4.3.2.2 in 
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Enter from FH PLME 



Return to FH PLME 

(on interrupt for SETFREQ, 

PHY RESET, etc.) 



PHY-TXSTART.request 
(TXVECTOR) 




PHY-RXSTART.indication 
(RXVECTOR) 

PHY-RXEND.indication 
(RXERROR= no_error) 



PHY-TXEND.confirm 
(STATUS) 



PHY-RXEND.indication 
(RXERROR=type) 



Figure 73— PLCP top-level state diagram 



PHY-TXSTART.req 
JTXVECTOR) 



Start Transmit 



• PHY-TXSTART. 
confirm 



Switch to Transmit 


• PMD TX 
(RF.STAT 
fdwein 


RX.req 
E=transmit) 



Ramp on 



* PMD_RAMP,req 
( RAM P_STATE =on) 
[dwell] 



Transmit Preamble 



[send 80 bit sync field and 
16 bit start frame detim] 
♦ PMD_DATAreq 
(TXDJJNIT) 



Transmit Header 



[combine PLW, PSF, and 
HEC; calculate header 
bias (see Data Whitener 
Encoding Procedure); 
transmit header] 
• PMD_DATA.req 
(TXDJJNIT) 



Transmit PSDU 



[Process data with PSDU 
data whitener (see Data 
Whitener Encoding 
Procedure); 

transmit whitened data] 

• PH Y-DATA. req (D ATA) 

• PHY-DATA-confirm 
•PMD DATA req 
(TXDJJNIT) 



Ramp down 



• PHY-TXEND.req 

• PHY-TXEND.confirm 

• PMD_RAMP.req 
<RAMP_STATE=off) 



Switch to Rx 



• PMD_TXRX.req 
(RF_STATE=receive) 



Go to CS/CCA Proc 



Figure 74 — Transmit state machine 
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sufficient time to send the bits at their designated bit slot time. The PLCP shall add the PLCP Header to the 
start of the PSDU data. 

Prior to transmitting the first PSDU data bit, the PLCP shall send a P H Y-TX START.confirm message to the 
MAC indicating that the PLCP is ready to receive an MPDU data octet. The MAC will pass an MPDU data 
octet to the PHY with a PHY- DATA . req u e s t ( DATA ) , which the PHY will respond to with a PHY- DATA. con- 
firm. This sequence o f P H Y- DATA . req uest( DATA) and PHY- DATA. confirm shall be executed until the last 
data octet is passed to the PLCP. During transmission of the PSDU data, each bit of the PSDU shall be 
processed by the data whitener algorithm defined in Figure 75 and described in 14.3.2.3. Each PSDU data 
octet is processed and transmitted lsb first and msb last. 



Data whitener encoding algorithm: 

/* If msb of stuff symbol = 1 then the next block is inverted; 0 = not inverted 7 
/* Accumulate PLCP Header; begin stuffing on first bit of the PSDU 7 

/********* Calculate number of32-symbol BSE blocks required to send PSDU; 

no padding is necessary when the number of symbols is not a multiple of 32 *********/ 
Input parameter: number_of_PSDU_octets, rate; /* rate is 1 or 27 

number_of_symbols= (number_of_PSDU_octets *8) /rate; 
number_of_blocks_in_packet = truncate{(number_of_ symbols + 31 ) / 32)}; 

/********* Accumulate the bias in the header to use in calculating the inversion state of the first 

block of PSDU data *•**•***•/ 
Read in header {b(1 ),...,b(32)}; /* b(1) is first bit in 7 

header_bias = Sum{weight(b(1)),...,weight(b{32))}; 

/* calculate bias in header; weights are defined in Table 31*/ 

Transmit {b(1 ) b(32)}; /* no stuffing on header 7 

accum=header_bias; /* initialize accum 7 

Initialize scrambler to all ones; 

/********* Whiten the PSDU data with scrambler and BSE encoder *********/ 

For n = 1 to number_of_blocks_in_packet 

{ 

b(0) = 0 for 1 Mbit/s; b(0)=00 for 2 Mbit/s; /* b(0) is the stuff symbol 7 

N = min(32, number_of_symbols); /* N= block size in symbols 7 

Read in next symbol block {b(1),...,b(N)}; /* b(n) = {0,1} or {0,1 ,2,3}; 

1 - 8 octets, use PHY-DA TA . req(DA TA), PHY-DA TA. confirm for each octet7 

Scramble (b(1) b(N)}; r see 14,3.2.37 

bias_next_block = Sum{weight(b(0)) weight(b(N))}; /* calculate bias with b(0)=0 7 

/***** if accum and bias of next block has the same sign, then invert block; 

if accum=0 or bias_ nexf. btock=0, don 't invert *****! 
If {[accum * bias_next_block > 0] then 
{ 

Invert {b(0),... t b(N)}; /* Invert deviation, or, negate msb of symbol 7 
bias_next_block = - bias_next_block; 

} 

accum = accum +"bias_next_block; 

transmit {b(0) b(N)}; /* b(0) is first symbol out 7 

number_of symbols = number_of_symbols - N 

} 



Figure 75 — Data whitener encoding procedure 
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After the last MPDU octet is passed to the PLCP, the MAC will indicate the end of the frame with a 
PHY- TXEND. req uest . After the last bit of the PSDU data has completed propagation through the radio and 
been transmitted on the air, the PLCP shall complete the transmit procedure by sending a PHY- TXEND. con- 
firm to the MAC sublayer, ramp off the power amplifier in the manner prescribed in 14.6, and switch the 
PHY PMD circuitry from transmit to receive state. The execution shall then return to the CS/CCA proce- 
dure. 

The weights assigned to each value of the symbols are defined in Table 3 1 for the 1 Mbit/s (2GFSK) and 
2 Mbit/s (4GFSK) symbols. 



Table 31— PLCP field bit descriptions 



2GFSK 


4GFSK 


Weight 




to 


3 


I 




2 




ll 


1 


Center 


Center 


0 




01 . 


-1 


0 




-2 




00 


-3 



14.3.3.1 .2 Transmit state timing 

The transmit timing illustrated in Figure 76 is defined from the instant that the PHY- TXSTART.requestfTXVEC- 
TOR) is received from the MAC sublayer. The PLCP shall switch the PMD circuitry from receive to transmit, 
turn on and settle the transmitter, and begin transmitting the first bit of the preamble at the antenna within a 
maximum of 20 us of receiving the PHY- TXSTARTrequestfTXVECTOR) . The PLCP Preamble shall be trans- 
mitted at 1 Mbit/s and be completed in 96 us. The PLCP Header shall be transmitted at 1 Mbit/s and be 
completed in 32 us. The variable length PSDU shall be transmitted at the selected data rate. After the last bit of 
the PSDU data has completed propagation through the radio and been transmitted on the air, the PLCP shall 
send the PHY- TXEND. confirm to the MAC sublayer. The PLCP shall turn off the transmitter, reducing the 
output energy to less than the specified off-mode transmit power within the time specified in 14.6. At the end of 
the power amplifier ramp down period, the PLCP shall switch the PMD circuitry from transmit to receive. 

14.3.3.2 Carrier sense/clear channel assessment (CS/CCA) procedure 

The PLCP CS/CCA procedure is executed while the receiver is turned on and the STA is not currently 
receiving or transmitting a packet. The CS/CCA procedure is used for two purposes: to detect the start of a 
network signal that can be received (CS) and to determine whether the channel is clear prior to transmitting 
a packet (CCA). 

14.3.3.2.1 CS/CCA state machine 

Timing for priority (PIFS, DfFS), contention backoff (slot times), and CS/CCA assessment windows is defined 
relative to the end of the last bit of the last packet on the air. The CS/CCA state machine is shown in Figure 77. 
The PLCP shall perform a CS/CCA assessment on a minimum of one antenna within a MAC contention back- 
off slot time of 50 us. The PLCP shall be capable of detecting within the slot time an FH PHY conformant 
signal that is received at the selected antenna up to 22 us after the start of the slot time with the synchronous 
detection performance specified in 14.6,15.3. Subclause 14.6.15.3 specifies detection performance with 
zero-one sync patterns and with random data patterns. If a start of a transmission is asynchronous with the BSS 
and arrives after the start of the slot but at least 1 6 us prior to the end of the slot, the PLCP shall indicate a busy 
channel prior to the end of the slot time with the asynchronous detection performance specified in 14.6.15.3. 
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The CCA indication immediately prior to transmission shall be performed on an antenna with essentially the 
same free space gain and gain pattern as the antenna to be used for transmission. The method of determining 
CS/CCA is unspecified except for the detection performance of a conformant method as specified in 14.6.15.3^ 



Start CS/CCA Procedure 



[set countdown_timer ] 



CS/CCA Assessment 



{Check for 
PHY-TXSTART.req or 
PHY-CCARESETreq; 
Perform CS/CCA ; 
Update countdown^timer 
Reset CS/CCA 
Assessment when 
countdown_timer reaches 
zero] 

• PMD _ANTSEL req 



Channel 
busy 



Report Channel Busy 



• PHY-CCA.ind 
(STATUS=busy) 



SFD/PLCP Header Search 



[Wait until valid SFD and 
PLCP headerdetected or 
timeout expires) 



PHY-TXSTART.req 
(TXVECTOR) received 



Go to TX Procedure 



(TXVECTOR) 



PHY-CCARESET.req 
received 



Clear countdown _timer 



■ PHY-CC ARE SET. confirm 



Channel 
idle 



ChecK countdown_timer 



[Test countdown_timerj 



countdown 
timer =0 



Report Channel Idle 



• PHY-CCA.ind 
(STATUS=idle) 



countdown 
_timer>0 



Report Channel Busy 



* PHY-CCAJnd 
(STATUS=busy) 



Timeout 



Valid SFD and PLCP 
headerdetected 



Go to RX Procedure 



* PHY-RXSTART.tNO 
(RXVECTOR) 



Figure 77— CS/CCA state machine 



If a PHY- TXSTART. request (TXVECTOR) is received, the CS/CCA procedure shall exit to the transmit 
procedure within 1 us. If a PHY-CCARESET request is received, the PLCP shall reset the CS/CCA state 
machine to the state appropriate for the end of a complete received frame. This service primitive is generated 
by the MAC at the end of a NAV period. The PHY shall indicate completion of the request by sending a 
PH Y- CCARESETconfirm to the MAC. 

If a CS/CCA assessment returns a channel idle result, the PHY shall send a PHY-CC A. indicate (STA- 
TUS^ idle) to the MAC. 

If a CS/CCA assessment returns a channel busy result, the PHY shall send a PHY-CCA.indicate(STA- 
TUS=busy) to the MAC. Upon a channel busy assessment, the PLCP shall stop any antenna switching prior 
to the earliest possible arrival time of the SFD and detect a valid SFD and PLCP Header if received. A valid 
PLCP Header is defined as containing valid PLCP Length Word and PHY Signaling field values and a valid 
HEC field. If a valid SFD/PLCP Header is detected, the CS/CCA procedure shall send a 
PHY-RXSTART.indicate(RXVECTOR) message to the MAC sublayer and exit to the receive procedure. 
The PLCP shall dwell and search for the SFD/PLCP Header for a minimum period longer than the latest 
possible arrival time of the SFD/PLCP Header. Indication of a busy channel does not necessarily lead to the 
successful reception of a frame. 
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The octet/bit count remaining may be a nonzero value when returning from the receive procedure if a signal 
in the process of being received was lost prior to the end as determined from the Length field of a valid 
PLCP Header. The countdown timer shall be set to the octet/bit count and used to force the CS/CCA indica- 
tion to remain in the BUSY state until the predicted end of the frame regardless of actual CS/CCA indica- 
tions. 

However, if the CS/CCA procedure indicates the start of a new frame within the countdown timer period, it 
is possible to transition to the receive procedure prior to the end of the countdown timer period. If the PHY 
transitions to receive under these conditions, the countdown timer shall be reset to the longer of ( 1 ) the 
remaining time of the current frame or (2) the length of the new frame. 

When a nonzero countdown timer reaches zero, the PLCP shall reset the CS/CCA state machine to the state 
appropriate for the end of a complete received frame and the CS/CCA indication shall reflect the state of the 
channel. 

If the receive procedure encountered an unsupported rate error, the PLCP shall keep the CS/CCA state at 
Busy for the duration of the frame by setting the countdown timer to the value corresponding to the calcu- 
lated time based on the information in the PLCP Header and the 33/32 expansion factor. 

14.3.3.2.2 CS/CCA state timing 

Timing for priority (PIFS, DIFS), contention backoff (slot times), and CS/CCA assessment windows is 
defined relative to the end of the last bit of the last packet on the air. The PLCP shall perform a CS/CCA 
assessment on a minimum of one antenna within a slot time. The appropriate CS/CCA indication shall be 
available prior to the end of each 50 us slot time with the performance specified in 1 4.6. See Figure 78. 

If a STA has not successfully received the previous packet, the perceived packet end time and slot boundary 
times will have a higher uncertainty for that STA. 

14.3.3.3 PLCP receive procedure 

The PLCP receive procedure is invoked by the PLCP CS/CCA procedure upon detecting a portion of the 
preamble sync pattern followed by a valid SFD and PLCP Header. 

14.3.3.3.1 Receive state machine 

The PLCP receive procedure shown in Figure 79 includes functions that must be performed while the PPDU is 
being received. The PLCP receive procedure begins upon detection of a valid SFD and PLCP Header in the CS/ 
CCA procedure. The PLCP shall set a PPDU octet/bit counter to indicate the last bit of the packet, receive the 
PPDU bits, and perform the data whitening decoding procedure shown in Figure 80 on each PPDU bit. The 
PLCP shall pass correctly received data octets to the MAC with a series of PHY-DA TA . indicate (DA TA ) . After 
the last PPDU bit is received and the last octet is passed to the MAC, the PLCP shall send a PHY-RXEND. indi- 
cate (RXERROR =no_error) to the MAC sublayer. Upon error-free completion of a packet reception, the PLCP 
shall exit the receive procedure and return to the PLCP CS/CCA procedure with the octet/bit count set to 0. 

If the PLCP Header was decoded without a CRC error but encountered an unsupported rate, then the PLCP 
shall immediately complete the receive procedure with a PHY-RXEND .indicate (RXERROR = 
unsupported _rate) to the MAC, and return to the CS/CCA procedure with the octet/bit count remaining and 
the data rate value contained in the PLCP Header. 

If an error was detected during the reception of the PPDU, the PLCP shall immediately complete the receive 
procedure with a PHY-RXEND.indicate(RXERROR^carrierJost) to the MAC, and return to the CS/CCA 
procedure with the octet/bit count remaining and the data rate value contained in the PLCP Header. 
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Start Receive procedure 




► 


(RX VECTOR) 





Receive PLCPPDU 



[Load byte/bit length 

counter; 
RXERROR = no error] 



error 
detected 



Data whitener decoding 
(See Data Whitener 
Decoding Procedure) 



• PMD_DATA.ind 
[Decode data] 
[If error detected, set 
RXERROR = error type] 
[Passoctets up to MAC) 
• PHY-DATA.ind(DATA) 







Complete RX procedure 


^ 


Go to CS/CCA Proc 




• PHY-RXEND.ind 
(RXERROR) 


<4 


[ byte/bitcount remaining, 
datarate] 







Figure 79 — Receive state machine 



Data whitener decoding algorithm: 

/* If msb of stuff symbol = 1 then the next block is inverted; 0 = not inverted 7 
r Stuffing begins on first symbol ofPLCP Header following the SFD 7 
/* Algorithm begins after verifying validity of header with HEC 7 

/********* Read header •****"**/ 

Read in header {b(1 ),...,b(32)}; /* b(1) is first bit in 7 

Get number_of_PSDtLoctets, rate from header; /* rate is 1 or 2*/ 

number_of_symbols = (number_of_PSDU_octets*8)/rate 
number_of_blocks_in_packet = truncate{(number_of_ symbols + 31) / 32}; 
Initialize scrambler to all ones; 

/********* De-whiten the PPDU data with BSE decoder and de-scrambler *********/ 

For n = 1 to number_of_blocks_in_packet 

{ 

N = min(32, # of symbols remaining); r N= block size in symbols 7 

Read in next block {b(0),...,b(N)};/ * b(n) = {0,1} or {0, 1,2,3} 7 

If {[msb of b(0)=1] then Invert {b(1 ),...,b(N)}; r if invert bit=true 7 

Descramble{b(1),...,b(N)}; rsee 14.3.2.3V 

Send {b(1),... ( b(N)}to MAC 

f* 1 - 8 octets; use PHY-DATA.ind(DATA) for each octet 7 

} 



Figure 80 — Data whitener decoding procedure 
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14.3.3.3.2 Receive state timing 

The receive state timing shown in Figure 8! is defined to begin upon detection of a valid SFD and PLCP 
Header in the CS/CCA procedure. The PLCP shall begin receiving the variable length whitened PSDU 
immediately after the end of the last bit of the PLCP Header. The PLCP shall send a PHY-RXEND.indi- 
cate(RXERROR) after receiving the last PPDU data bit. 

If any error was detected during the reception of the PPDU, the PLCP may send a PHY-RXEND.indi- 
cate(RXERROR) and terminate the receive procedure before the last bit arrives. 

14.4 PLME SAP layer management 

14.4.1 Overview 

This subclause describes the services provided by the FHSS PLME to the upper layer management entities. 
The PLME/PMD services are defined in terms of service primitives. These primitives are abstract represen- 
tations of the services and are not intended to restrict implementations. 

14.4.2 FH PHY specific MAC sublayer management entity (MLME) procedures 

14.4.2.1 Overview 

The specific MAC sublayer management entity (MLME) procedures required for operating the FHSS PHY 
are specified in this portion of the subclause. The relationship between the MLME and FH PLME proce- 
dures is also described. 

14.4.2.2 FH synchronization 

The MLME of a compliant FH PHY STA shall perform the FH time synchronization procedure as defined in 
1 1.1 .5. This procedure provides for synchronized frequency hopping for all compliant FH PHY STAs within 
a single BSS or ad hoc network. The FH PLME accepts PL ME- SET. request commands from the MLME to 
change the tune frequency at the time determined by the MLME. The tune frequency is changed by updating 
any combination of the Set, Pattern, and Index PHY MI B parameters. 

14.4.3 FH PHY layer management entity state machines 

14.4.3.1 Overview 

This portion of this subclause describes the FH PHY layer management state machines to turn the PMD on/ 
off, reset the PLCP state machine, and change the frequency hop channel. 

14.4.3.2 PLME state machine 

The PLME state machine in Figure 82 begins with a PLME-SET. request (dot U CurrentPowerState= ON) , 
which turns on the PHYcireuitry, resets the PLME and PLCP state machines, and sends a PLME-SET.con- 
firm. The MAC then sends a series of three PLME-SET, request primitives to update the dot I ICurrentSet, 
dotl ICurrentPattern, and dotl lCurrentlndex PHY MIB parameters, which together tune the PMD to the 
selected channel. The PLME then transfers execution to the PLCP state machine as defined in 14.3.3. 

Upon receiving a PLME request from a higher-level LME, the PLCP shall return execution to the PLME 
state machine and process the request. A PLME-RESET.request shall cause a reset to the PLME and PLCP 
state machines. A PLME-SET. request updating the dotl lCurrentlndex or a combination of the 
dotl ICurrentSet, dotl ICurrentPattern, and dotl lCurrentlndex shall cause the PLCP to terminate a receive 
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or CS/CCA process and change frequency before returning to the PLCP state machine. A 
PLME-SET.request(dotl ICurrentPowerState=OFF) shall cause the PLCP to terminate a receive or CS/CCA 
process, power down the PMD circuitry, and return the PLME state machine to the idle state. 
PLME-SET.requests to any parameter other than the ones identified within this paragraph shall be executed 
and control shall be returned to the PLCP state machine. The MAC should not send a PLME request while 
the PLCP is in the transmit state. 

All PLME-GET.requests shall be processed in parallel and with no interruption to the execution of any state 
machine in process. 



PLME-SET.req 
(power_state, ON) i 








Power up/Reset PHY 




Idle 




Power down PMD 


< 


A 


(Power up/reset PHY] 
* PMD_PWRMGNT.req 
(mode = ON) 
* PLME-SET.confirm 
{Dot1 1 CurrentPowerState=ON) 


{Wait for PLME-SET.req 
{Dol 1 1 CurrentPowerState=ON >] 


[Power down sequence] 
• PMD_PWRMGNT.req 
(mode=OFF) 
• PLME-SET.confirm 
(Dot1 1 CurrentPowerState=OFF) 



Reset PHY 



[Reset PLCP PLME, 

PMD] 
• PLME-RESET.con 

(status) 



Set tune frequency 



• PHY-CCA.ind 
(STATUS=Busy) 

• PMD_FREQ.req 

(CHNLJD) 
[Dwell for freq hop 

settling time] 
• PLME-SET.confirm 

• PHY-CCA.ind 
(STATUS=to!e) 



PLCP State Machine 



[Check for PLME 
commands] 



PLME-SET.req(dot11 CurrentSet) 
and/or 

PLM E-SET.req(dot1 1 CurrentPattem ) 
and/or 

PLME-SET.req(dot11 Currentlndex) 



Execute PLME_SET.req 



[Al other parameters] 



PLME-SET.req(olher parameters) 



PLME-RESET.req 



PLME-SET.req(aCurrentPowerState=OFF) 

Figure 82— PLME state machine 



14.4.3.3 PLME management primitives 

The FH PLME uses the generic management primitives defined in 10.2 to manage all FH PHY parameters. 
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14.5 FHSS PMD sublayer services 
14.5.1 Scope and field of application 

The PMD services provided to the PLCP for the FHSS PHY are described in this subclause. Also defined in 
this subclause are the functional, electrical, and RF characteristics required for interoperability of implemen- 
tations conforming to this specification. The relationship of this specification to the entire FHSS PHY is 
shown in Figure 83. 



PHY 


PLCP 




L 


Sublayer 




A 


PMD SAP 


PHY 


Y 




Layer 
Management 


E 




R 


PMD ^_ 

Sublayer 


Entity 



Figure 83 — PMD layer reference model 



14.5.2 Overview of services 

In general, the FHSS PMD sublayer accepts PLCP sublayer service primitives and provides the actual means 
by which the signals required by these primitives are imposed onto the medium. In the FHSS PMD sublayer 
at the receiver the process is reversed. The combined function of the transmitting and receiving FHSS PMD 
sublayers results in a data stream, timing information, and receive parameter information being delivered to 
the receiving PLCP sublayer. 

14.5.3 Overview of interactions 

The primitives associated with the IEEE 802.11 PLCP sublayer to the FHSS PMD sublayer fall into the 
following two basic categories: 

a) Service primitives that support PLCP peer-to-peer interactions; 

b) Service primitives that have local significance and support sublayer-to-sublayer interactions. 

14.5.4 Basic service and options 

All of the service primitives described in this subclause are considered mandatory unless otherwise specified. 
14.5.4.1 PMD_SAP peer-to-peer service primitives 

Table 32 indicates the primitives for peer-to-peer interactions. 



Table 32— PMD-SAP peer-to-peer service primitives 



Primitive 


Request 


Indicate 


Confirm 


Response 


PMD_DATA 


X 


X 
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14.5.4.2 PMD_SAP sublayer-to-sublayer service primitives 

Table 33 indicates the primitives for sublayer-to-sublayer interactions. 



Table 33 — PMD_SAP sublayer-to-sublayer service primitives 



Primitive 


Request 


Indicate 


Confirm 


Response 


PMDJTXRX 










PMD_PA_RAMP 


X 








PMD_ANTSEL 


X 








PMD_TXPWRLVL 


X 








PMD_FREQ 


X 








PMD_RSSI 




X 






PMD_PWRMGMT 


X 









14.5.4.3 PMD_SAP service primitives parameters 

Table 34 shows the parameters used by one or more of the PMD_SAP service primitives. 



Table 34 — List of parameters for PMD primitives 



Parameter 


Associate primitive 


Value 


TXD_UNIT 


PM D_DATA.request 


1 Mbit/s: 0, 1 

2 Mbit/s: 0, 1,2,3 


RXDJJNIT 


PMD_DATAindicate 


1 Mbit/s: 0, 1 

2 Mbit/s: 0, t,2,3 


RF.STATE 


PMD.TXRX.request 


TRANSMIT, RECEIVE 


RAMP_STATE 


PMD_PA_ RAM P. request 


ON, OFF 


ANTENNA_STATE 


PM D_ANTS EL. request 


1 to 255 


TXPWR_LEVEL 


PMD_TXPWRLVL. request 


LEVEL1, LEVEL2, LEVEL3, LEVEL4 


CHNLJD 


PMD.FREQ.request 


2-80 inclusive 


STRENGTH 


PMD_RSSI.indicate 


0 to RSSI Max 


MODE 


PMD.PWRMGMT.request 


ON, OFF 



14.5.5 PMD.SAP detailed service specification 

This subclause describes the services provided by each PMD primitive. 
14.5.5.1 PMD_DATA.request 
14.5.5.1.1 Function 

This primitive defines the transfer of data from the PLCP sublayer to the PMD entity. 
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14.5.5.1.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

P M D_ DATA . req ue st (TXD_UNIT) 

The TXD_UNIT parameter can take on one of two values: one or zero. This parameter represents a single 
data bit. The effect of this parameter is that the PMD will properly modulate the medium to represent ones or 
zeros as defined in the FHSS PMD modulation specifications for a given data rate. 

14.5.5.1. 3 When generated 

This primitive is generated by the PLCP sublayer to request the transmission of a single data bit on the PMD 
sublayer. The bit clock is assumed to be resident or part of the PLCP and this primitive is issued at every 
clock edge once the PLCP has begun transmitting data. 

14.5.5.1.4 Effect of receipt 

The receipt of this primitive will cause the PMD entity to encode and transmit a single data bit. 

14.5.5.2 PMD_DATA.indicate 

14.5.5.2.1 Function 

This primitive defines the transfer of data from the PMD entity to the PLCP sublayer. 

14.5.5.2.2 Semantics of the service primitive 
The primitive shall provide the following parameter: 

PMD_DATA.indicate (RXD_UNIT) 

The RXD_UN1T parameter can take on one of two values: one or zero. This parameter represents the current 
state of the medium as determined by the FHSS PMD modulation specifications for a given data rate. 

14.5.5.2.3 When generated 

The PMD_DATA. indicate is generated to all receiving PLCP entities in the network after a 
PMD_DATA.request is issued. 

14.5.5.2.4 Effect of receipt 

The effect of receipt of this primitive by the PLCP is unspecified in this standard. 

14.5.5.3 PMD.TXRX.request 
14.5.5.3.1 Function 

This primitive is used to place the PMD entity into the transmit or receive function. 



168 



Copyright © 1999 IEEE. All rights reserved. 



ISO/IEC 8802-11: 1999(E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.11, 1999 Edition 

1 4.5.5.3.2 Semantics of the servic primitive 

The primitive shall provide the following parameter: 

PMDJTXRX.request (RF.STATE) 

The RF_STATE parameter can take on one of two values: TRANSMIT or RECEIVE. When the value of the 
primitive is TRANSMIT, the RF state of the radio is transmit. If the value of the primitive is RECEIVE, the 
RF state of the radio is receive. 

14.5.5.3.3 When generated 

This primitive is generated whenever the mode of the radio needs to be set or when changing from transmit 
to receive or receive to transmit. 

14.5.5.3.4 Effect of receipt 

The receipt of this primitive by the PMD entity will cause the mode of the radio to be in either transmit or 
receive. 

14.5.5.4 PMD_PA_RAMP.request 

14.5.5.4.1 Function 

This primitive defines the start of the ramp up or ramp down of the radio transmitter's power amplifier. 

14.5.5.4.2 Semantics of the service primitive 
The primitive shall provide the following parameter: 

PMD_PA_RAMRrequest (RAMP.STATE) 

The RAMP_STATE parameter can take on one of two values: ON or OFF. When the value of the primitive is 
ON, the state of the transmit power amplifier is "on " If the value of the primitive is OFF, the state of the 
transmit power amplifier is "off." 

14.5.5.4.3 When generated 

This primitive is issued only during transmit and to establish the initial state. It is generated by the PLCP at 
the start of the transmit function to turn the transmitter's power amplifier "on." A power amplifier ramp-up 
period follows the change of state from "off" to "on " After the PLCP has transferred all required data to the 
PMD entity, this primitive again will be issued by the PLCP to place the transmit power amplifier back into 
the "off* state. A power amplifier ramp-down period follows the change of state from "on" to "off." 

14.5.5.4.4 Effect of receipt 

The receipt of this primitive by the PMD entity will cause the transmit power amplifier to turn on or off 

14.5.5.5 PMD_ANTSEL.request 
14.5.5.5.1 Function 

This primitive is used to select which antenna the PMD entity will use to transmit or receive data. 
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14.5.5.5.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD_ANTSEL. request ( ANT EN NA_STAT E ) 

The ANTENNA_STATE parameter can take on values from one to /V (where N is the number of antennas 
supported). When the value of the primitive is a ONE, the PMD will switch to antenna 1 for receive or trans- 
mit; if the value of the primitive is TWO, the PMD entity will switch to antenna 2 for receive or transmit, etc. 

14.5.5.5.3 When generated 

This primitive is generated at various times by the PLCP entity to select an antenna. During receive, this 
primitive can be used to manage antenna diversity. During transmit, this primitive can be use to select a 
transmit antenna. This primitive will also be used during CCA. 

14.5.5.5.4 Effect of receipt 

The receipt of this primitive by the PMD entity will cause the radio to select the antenna specified. 
14.5.5.6 PMD_TXPWRLVL. request 

14.5.5.6.1 Function 

This primitive defines the power level the PMD entity will use to transmit data. 

14.5.5.6.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMDJTXPWRLVL. request (TXPOWER_LEVEL) 
The TXPOWER_LEVEL parameter can be one of the values listed in Table 35. 



Table 35 — Transmit power levels 



TXPWR_LEVEL 


Level description 


LEVEL 1 


Defined as TxPowerLevell in MIB 


LEVEL2 


Defined as TxPowerLevel2 in MIB 


LEVEL3 


Defined as TxPowerLeveB in MIB 


LEVEL4 


Defined as TxPowerLevel4 in MIB 


LEVEL5 


Defined as TxPowerLevelS in MIB 


LEVEL6 


Defined as TxPowerLevel6 in MIB 


LEVEL7 


Defined as TxPowerLevel7 in MIB 


LEVEL8 


Defined as TxPowerLevel8 in MIB 



14.5.5.6.3 When generated 

This primitive is generated as part of the transmit sequence. 
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14.5.5.6.4 Effect of receipt 

The receipt of this primitive by the PMD entity will cause the transmit power level to be modify. 

14.5.5.7 PMD_FREQ. request 

14.5.5.7.1 Function 

This primitive defines the frequency the PMD entity will use to receive or transmit data. Since changing the 
radio frequency is not an immediate function, this primitive serves also as an indication of the start of this 
process. The completion of this process is dictated by other PMD specifications. 

14.5.5.7.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD.FREQ.request (CHANNELED) 
The CHANNELED parameter can be one of the values listed in Table 38, Table 39, Table 40, or Table 4 1 . 

14.5.5.7.3 When generated 

This primitive is generated by the PLCP whenever a change to a new frequency is required. 

14.5.5.7.4 Effect of receipt 

The receipt of this primitive by the PMD entity will cause the radio to change to a new frequency defined by 
the value of the CHNLJD. 

14.5.5.8 PMD_RSSI.indicate 

14.5.5.8.1 Function 

This primitive transfers a receiver signal strength indication of the physical medium from the PMD sublayer 
to the PLCP sublayer. This value will be used by the PLCP to perform any diversity or clear channel assess- 
ment functions required by the PLCP or other sublayers. 

14.5.5.8.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD.RSSI.indicate (STRENGTH) 

The STRENGTH parameter can be a value from 0 to 15. This parameter is an indication by the PMD 
sublayer of the magnitude of the energy observed at the selected antenna. This reported value is used to 
generate the RSSi term in the PHY-RXSTART.ind(RX VECTOR) primitive and might also be used by any 
diversity function. Since RSSI is only used in a relative manner by the MAC sublayer, this parameter is 
defined to have no more than 16 values, ranging from 0 through RSSI_Max. The value zero is the weakest 
signal strength, while RSSI_Max is the strongest signal strength. 

14.5.5.8.3 When generated 

This primitive is generated continually by the PMD entity to transfer a receive signal strength indication to 
the PLCP. 
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14.5.5.8.4 Effect of receipt 

The effect of receipt of this primitive by the PLCP is unspecified in this standard. 
14.5.5.9 PMD_PWRMGMT,request 

14.5.5.9.1 Function 

This primitive is used by the higher-layer entities to manage or control the power consumption of the PMD 
when not in use. This allows higher-layer entities to put the radio into a sleep or standby mode when receipt 
or sending of any data is not expected. 

14.5.5.9.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD_PWRMGMT.request (MODE) 

The MODE parameter can have one of two values: ON or OFF. When the value of the parameter is ON, the 
PMD entity will enter into a fully functional mode that allows it to send or receive data. When the value of 
the parameter is OFF, the PMD entity will place itself in a standby or power-saving mode. In the low-power 
mode, the PMD entity is not expected to be able to perform any request by the PLCP, nor is it expected to 
indicate any change in PMD state or status. 

14.5.5.9.3 When generated 

This primitive is delivered by the PLCP but actually is generated by a higher-layer management entity. 

14.5.5.9.4 Effect of receipt 

Upon receipt of this primitive, the PMD entity will enter a fully functional or low power consumption state 
depending on the value of the primitive's parameter. 

14.6 FHSS PMD sublayer, 1.0 Mbit/s 

14.6.1 1 Mbit/s PMD operating specifications, general 

In general, the PMD accepts convergence layer service primitives and provides the actual means by which 
the signals required by these primitives are imposed on the medium. In the PMD sublayer at the receiver, the 
process is reversed. The combined function of the transmitting and receiving PMD sublayers results in a data 
stream, timing information, and receive parameter information being delivered to the receiving convergence 
sublayer. 

14.6.2 Regulatory requirements 

Wireless LANs implemented in accordance with this standard are subject to equipment certification and 
operating requirements established by regional and national regulatory administrations. The PMD specifica- 
tion establishes minimum technical requirements for interoperability, based upon established regulations for 
Europe, Japan, and North America at the time this standard was issued. These regulations are subject to revi- 
sion, or may be superseded. Requirements that are subject to local geographic regulations are annotated 
within the PMD specification. Regulatory requirements that do not affect interoperability are not addressed 
within this standard. Implementors are referred to the following regulatory sources for further information. 
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Operation in countries within Europe, or other regions outside Japan or North America, may be subject to 
additional or alternative national regulations. 



The documents listed below specify the current regulatory requirements for various geographic areas at the 
time this standard was developed. They are provided for information only, and are subject to change or revi- 
sion at any time. 



Geographic 
area 


Approval standards 


Documents 


Approval authority 


Europe 


European Telecommunications 
Standards Institute (ETSI) 


ETS 300-328, 
ETS 300-339 


National type approval 
authorities . 


France 


Regie technique applicable aux 
equipements radioelectriques 
de transmission de donnees a 
large bande fonctionnant dans 
la bande de frequences a 2,4 
GHz et utilisant la technique 
de Tetalement de spectre 
(Edition fevrier 1995) 


SP/DGPT/ATAS/23, 
ETS 300-328, 
ETS 300-339 


Direction Generate des Postes 
et Telecommunications 
(DGPT) 


Japan 


Association of Radio Industries 
and Businesses (ARIB) 


RCR STD-33A 


Ministry of Telecommunica- 
tions (MKX) 


North America 
Canada 
USA 


Industry Canada (IC) 
Federal Communications 
Commission (FCC) 


GL3fi - 

CFR47, Part 15, Sections 
15.205, 15.209, 15.247 


IC 
FCC 


Spain 


Supplemento Del Numero 164 
Del Boletin Oficial Del 
Estado (Pubushed 10 July 
1991, Revised 25 June 1993) 


ETS 300-328, ETS 
300-339 


Cuadro Nacional De Atribu- 
cion De Frecuesias 



14.6.3 Operating frequency range 



A conformant PMD implementation shall be able to select the carrier frequency (F c ) from the full 
geographic-specific set of available carrier frequencies. Table 36 summarizes these frequencies for a number - 
of geographic locations. 



Table 36 — Operating frequency range 



Lower Limit 


Upper limit 


Regulatory range 


Geography 


2.402 GHz 


2.480 GHz 


2.400-2.4835 GHz 


North America 


2.402 GHz 


2.480 GHz 


2.400-2.4835 GHz 


Europe 3 


2.473 GHz 


2.495 GHz 


2.47 i-2.497 GHz 


Japan 


2.447 GHz 


2.473 GHz 


2.445-2.475 GHz 


Spain 


2.448 GHz 


2.482 GHz 


2.4465-2.4835 GHz 


France 


NOTE — The frequency ranges in this table are subject to the geographic-specific regulatory 
authorities. 



a Excluding Spain and France. 
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14.6.4 Number of op rating channels 

The number of transmit and receive frequency channels used for operating the PMD entity is 79 for the USA 
and Europe, and 23 for Japan. Table 37 summarizes these frequencies for a number of geographic locations. 
This is more fully defined in Table 38 through Table 41. 



Table 37 — Number of operating channels 



Minimum 


Hopping set 


Geography 


75 


79 


North America 


20 


79 


Europe 3 


Not applicable 


23 


Japan 


20 


27 


Spain 


20 


35 


France 


NOTE — The number of required hopping channels is subject to the 
geographic-specific regulatory authorities. 



Excluding Spain and France. 



14.6.5 Operating channel center frequency 

The channel center frequency is defined in sequential 1 .0 MHz steps beginning with the first channel, chan- 
nel 2.402 GHz for the USA and Europe excluding Spain and France, as listed in Table 38. The channel 
centers for Japan, starting at 2.473 GHz with 1 MHz increments, are listed in Table 39. The channel centers 
for Spain and France are listed in Table 40 and Table 41, respectively. 



Table 38 — Requirements in North America and Europe 
(excluding Spain and France; values specified in GHz) 



Channel # 


Value 


Channel # 


Value 


Channel # 


Value 


2 


2.402 


28 


2.428 


54 


2.454 


3 


2.403 


29 


2.429 


55 


2.455 


4 


2.404 


30 


2.430 


56 


2.456 


5 


2.405 


31 


2.431 


57 


2.457 


6 


2.406 


32 


2.432 


58 


2.458 


7 


2.407 


33 


2.433 


59 


2.459 


8 


2.408 


34 


2.434 


60 


2.460 


9 


2.409 


35 


2.435 


61 


2.461 


10 


2.410 


36 


2.436 


62 


2.462 


11 


2.411 


37 


2.437 


63 


2!463 


12 


2.412 


38 


2.438 


64 


2.464 
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Table 38— Requirements in North America and Europe 
(excluding Spain and France; valu s specified in GHz) (continued) 



Channel # 


Value 


Channel # 


Value 


Channel # 


Value 


13 


2.413 


39 


2.439 


65 


2.465 


14 


2.414 


40 


2.440 


66 


2.466 


15 


2.415 


41 


2.441 


67 


2.467 


16 


2.416 


42 


2.442 


68 


2.468 


17 


2.417 


43 


2.443 


69 


2.469 


18 


2.418 


44 


2.444 


70 


2.470 


19 


2.419 


45 


2.445 


71 


2.47! 


20 


2.420 


46 


2.446 


72 


2.472 


21 


2.421 


47 


2.447 


73 


2.473 


22 


2.422 


48 


2.448 


74 


2.474 


23 


2.423 


49 


2.449 


75 


2.475 


24 


2.424 


50 


2.450 


76 


2.476 


25 


2.425 


51 


2.451 


77 


2.477 


26 


2.426 


52 


2.452 


78 


2.478 


27 


2.427 


53 


2.453 


79 


2.479 










80 


2.480 



Table 39 — Requirements in Japan 
(values specified in GHz) 



Channel # 


Value 


Channel # 


Value 


Channel # 


Value 


73 


2.473 


81 


2.481 


89 


2.489 


74 


2.474 


82 


2.482 


90 


2.490 


75 


2.475 


83 


2.483 


91 


2.491 


76 


2.476 


84 


2.484 


92 


2.492 


77 


2.477 


85 


2.485 


93 


2.493 


78 


2.478 


86 


2.486 


94 


2.494 


79 


2.479 


87 


2.487 


95 


2.495 


80 


2.480 


88 


2.488 
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Table 40 — Requirements in Spain 
(values specified in GHz) 



Channel # 


i 

Value J Channel # 


Value 


Channel # 


Value 


47 


2.447 


56 


2.456 


65 




48 


2.448 


57 


2.457 


66 


2.466 


49 


2.449 


58 


2.458 


67 


2.467 


50 


2.450 


59 


2.459 


68 


2.468 


51 


2.451 


60 


2.460 


69 


2.469 


52 


2.452 


61 


2.461 


70 


2.470 


53 


2.453 


62 


2.462 


71 


2.471 


54 


2.454 


63 


2.463 


72 


2.472 


55 


2.455 


64 


2.464 


73 


2.473 



Table 41 — Requirements in France 
(values specified in GHz) 



Channel # 


Value 


Channel # 


Value 


Channel # 


Value 


48 


2.448 


60 


2.460 


72 


2.472 


49 


2.449 


61 


2.461 


73 


2.473 


50 


2.450 


62 


2.462 


74 


2.474 


51 


2.451 


63 


2.463 


75 


2.475 


52 


2.452 


64 


2.464 


76 


2.476 


53 


2.453 


65 


2.465 


77 


2.477 


54 


2.454 


66 


2.466 


78 


2.478 


55 


2.455 


67 


2.467 


79 


2.479 


56 


2.456 


68 


2.468 


80 


2.480 


57 


2.457 


69 


2.469 


81 


2.48! 


58 


2.458 


70 


2.470 


82 


2.482 


59 


2.459 


71 


2.471 







14.6.6 Occupied channel bandwidth 

Occupied channel bandwidth shall meet all applicable local geographic regulations for 1 MHz channel spac- 
ing. The rate at which the PMD entity will hop is governed by the MAC. The hop rate is an attribute with a 
maximum dwell time subject to local geographic regulations. 

14.6.7 Minimum hop rate 

The minimum hop rate shall be governed by the regulatory authorities. 
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14.6.8 Hop sequences 



The hopping sequence of an individual PMD entity is used to create a pseudorandom hopping pattern utiliz- 
ing uniformly the designated frequency band. Sets of hopping sequences are used to co-locate multiple PMD 
entities in similar networks in the same geographic area and to enhance the overall efficiency and throughput 
capacity of each individual network. 

An FH pattern, F x , consists of a permutation of all frequency channels defined in Table 38 and Table 39. For 
a given pattern number, x y the hopping sequence can be written as follows: 

F x -{f x (\)J x (2Uf x (p)} (1) 



where 



f x fi) is the channel number (as defined in 14.6.4) for i ^ frequency in X th hopping pattern; 
p is the number of frequency channels in hopping pattern (79 for North America and most of Europe, 
23 for Japan, 35 for France, 27 for Spain). 

Given the hopping pattern number, x, and the index for the next frequency, / (in the range 1 to p), the channel 
number shall be defined to be as follows: 

fx CO = WO + *] mod (79) + 2 in North America and most of Europe, with bfi) defined in Table 42. 

= [(/ - 1 ) x x] mod (23) + 73 in Japan. 

= [bfi) + jc] mod (27) + 47 in Spain with bfi) defined in Table 43. 

= [bfi) + jc] mod (35) + 48 in France with bfi) defined in Table 44. 



Table 42— Base-Hopping sequence bfi) for North America and most of Europe 



/ 


bfi) 


i 


bfi) 


/ 


bfi) 


i 


bfi) 


/ 


bfi) 


i 


bfi) 


i 


bfi) 


i 


bfi) 


1 


0 


11 


76 


21 


18 


31 


34 


4t 


14 


51 


20 


61 


48 


71 


55 


2 


23 


12 


29 


22 


11 


32 


66 


42 


57 


52 


73 


62 


15 


72 


35 


3 


62 


13 


59 


23 


36 


33 


7 


43 


41 


53 


64 


63 


5 


73 


53 


4 


8 


14 


22 


24 


71 


34 


68 


44 


74 


54 


39 


64 


17 


74 


24 


5 


43 


15 


52 


25 


54 


35 


75 


45 


32 


55 


13 


65 


6 


75 


44 


6 


16 


16 


63 


26 


69 


36 


4 


46 


70 


56 


33 


66 


67 


76 


51 


7 


71 


17 


26 


27 


21 


37 


60 


47 


9 


57 


65 


67 


49 


77 


38 


8 


47 


18 


77 


28 


3 


38 


27 


48 


58 


58 


50 


68 


40 


78 


30 


9 


19 


19 


31 


29 


37 


39 


12 


49 


78 


59 


56 


69 


1 


79 


46 


10 


61 


20 


2 


30 


10 


40 


25 


50 


45 


60 


42 


70 


28 
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Tabl 43 — Base-Hopping sequ nee b(i) for Spain 



/ 


b(i) 


i 


b(i) 


i 


b(i) 


1 


13 


10 


19 


19 


14 


2 


4 


11 


8 


20 


I 


3 


24 


12 


23 


21 


20 


4 


18 


13 


15 


22 


7 


5 


5 


14 


22 


23 


16 


6 


12 


15 


9 


24 


2 


7 


3 


16 


21 


25 


il 


8 


10 


17 


0 


26 


17 


9 


25 


18 


6 


27 


26 



Table 44 — Base-Hopping sequence b(i) for France 



I 


b(i) 


i 


b(i) 


/ 


bfi) 


1 


17 


13 


31 


25 


15 


2 


5 


14 


20 


26 


3 


3 


18 


15 


29 


27 


11 


4 


32 


16 


22 


28 


30 


5 


23 


17 


12 


29 


24 


6 


7 


18 


6 


30 


9 


7 


16 


19 


28 


31 


27 


8 


4 


20 


14 


32 


19 


9 


13 


21 


25 


33 


2 


10 


33 


22 


0 


34 


21 


11 


26 


23 


8 


35 


34 


12 


10 


24 


1 







The sequences are designed to ensure some minimum distance in frequency between contiguous hops. The 
minimum hop size is 6 MHz for North America and Europe, including Spain and France, and 5 MHz for Japan. 

The hopping pattern numbers x are divided into three sets. The sets are designed to avoid prolonged collision 
periods between different hopping sequences in a set. Hopping sequence sets contain 26 sequences for North 
America and Europe, and 4 sequences per set for Japan: 

For North America and most of Europe: 

.v = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75} Set 1 

x = { 1 ,4,7, 1 0, 1 3 , 1 6, 1 9,22,25,28,3 1 ,34,3 7,40,43,46,49,52,55,58,6 1 ,64,67,70,73,76} Set 2 

x = {2,5,8,1 1,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59,62,65,68,71,74,77} Set 3 
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For Japan: 

x= {6,9,12,15} Set 1 
x = {7,10,13,16} Set2 
x = {8,11,14,17} Set3 

For Spain: 

{0,3,6,9,12,15,18,21,24} Set 1 
jc = {1,4,7,10,13,16,19,22,25} Set 2 
jc= {2,5,8,11,14,17,20,23,26} Set 3 

For France: 

x= {0,3,6,9,12,15,18,21,24,27,30} Set 1 

.r = { 1 ,4,7, 10,13,16,19,22,25,28,31} Set 2 

jc = {2,5,8,1 1,14,17,20,23,26,29,32} Set 3 

The three sets of hopping sequences for North America and most of Europe, of 26 patterns each, are listed in 
Tables B.l, B.2, and B.3 in Annex B. Similarly, there are three sets for Japan of four patterns each. The three 
sets for Spain have nine patterns each. The three sets for France have 1 1 patterns each. The channel numbers 
listed under each pattern refer to the actual frequency values listed in Table 38 and Table 39. 

14.6.9 Unwanted emissions 

Conformant PMD implementations shall limit the emissions that fall outside of the operating frequency 
range, defined in Table 36, to the geographically applicable limits. 

14.6.10 Modulation 

The minimum set of requirements for a PMD to be compliant with the IEEE 802.1 1 FHSS PHY shall be as 
follows. 

The PMD shall be capable of operating using two-level Gaussian frequency shift key (GFSK) modulation 
with a nominal bandwidth bit-period (BT)=0.5. The PMD shall accept symbols from the set {{ 1 },{0} } from 
the PLCP. The symbol { 1 } shall be encoded with a peak deviation of giving a peak transmit frequency 
of (F c +fd)i which is greater than the carrier center frequency (F c ). The symbol {0} shall be encoded with a 
peak frequency deviation of giving a peak transmit frequency of {F^-fy. 

An incoming bit stream at 1 Mbit/s will be converted to symbols at Fclk=\ A/symbols/s, as shown in Table 45. 
Table 45— Symbol encoding into carrier deviation (1 Mbit/s, 2-GFSK) 



Symbol 


Carrier deviation 


I 


1/2 x h2 x Fclk 


0 


-l/2xh2xFclk 


NOTE — These deviation values are measured using the center sym- 
bol of 7 consecutive symbols of the same value. The instantaneous 
deviation will vary due to Gaussian pulse shaping. 
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The deviation factor hi for 2GFSFC (measured as difference between frequencies measured in the middle of 
0000 and 1111 patterns encountered in the SFD, divided by 1 MHz) will nominally be 0.32. 

The minimum frequency deviation, as shown in Figure 84, shall be greater than 110 kHz relative to the 
nominal center frequency F c . F<\ is the average center frequency of the last 8 bits of the Preamble Sync field, 
measured as the deviation at the midsymbol. Midsymbol is defined as the point that is midway between the 
zero crossings derived from a best fit to the last 8 bits of the Sync field. Maximum deviation is not specified, 
but modulation is subject to the occupied bandwidth limits of 14.6.5. 

The zero crossing error shall be less than ±1/8 of a symbol period. The zero crossing error is the time differ- 
ence between the ideal symbol periods and measured crossings of F c . This is illustrated in Figure 84. 




> Time 



Figure 84 — Transmit modulation mask 



14.6.11 Channel data rate 

A compliant IEEE 802.1 1 FHSS PMD shall be capable of transmitting and receiving at a nominal data rate 
of 1 .0 Mbit/s ± 50 parts per million (ppm). 

14.6.12 Channel switching/settling time 

The time to change from one operating channel frequency, as specified in 14.6.3, is defined as 224 us. A 
conformant PMD meets thfs switching time specification when the operating channel center frequency has 
settled to within ±60 kHz of the nominal channel center frequency as outlined in 14.6.3. 

14.6.13 Receive to transmit switch time 

The maximum time for a conformant PMD to switch the radio from the receive state to the transmit state and 
place the start of the first bit on the air shall be 19 us. At the end of this 19 us, the RF carrier shall be within 
the nominal transmit power level range, and within the described modulation specifications. 
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14.6.14 PMD transmit specifications 

The following portion of this subclause describes the transmit functions and parameters associated with the 
PMD sublayer. In general, these are specified by primitives from the PLCP, and the transmit PMD entity 
provides the actual means by which the signals required by the PLCP primitives are imposed onto the 
medium. 

14.6.14.1 Nominal transmit power 

The nominal transmit power of a frame is defined as the power averaged between the start of the first symbol 
in the PLCP Header to the end of the last symbol in the PLCP Header. When in the transmit state, the trans- 
mit power shall be within 2 dB of the nominal transmit power from the start of the Preamble SYNC field to 
the last symbol at the end of the frame. 

14.6.14.2 Transmit power levels 

Unless governed by more stringent local geographic regulations, the radiated emissions from compliant 
devices shall meet IEEE Std C95.1-I99I limits for controlled or uncontrolled environments, in accordance 
with their intended usage. In addition, all conformant PMD implementations shall support at least one power 
level with a minimum equivalent isotropically radiated power (EIRP) of 10 mW. 

14.6.14.3 Transmit power level control 

If a conformant PMD implementation has the ability to transmit in a manner that results in the EIRP of the 
transmit signal exceeding the level of 100 mW, at least one level of transmit power control shall be imple- 
mented. This transmit power control shall be such that the level of the emission is reduced to a level at or 
below 100 mW under the influence of said power control. 

14.6.14.4 Transmit spectrum shape 

Within the operational frequency band the transmitter shall pass a spectrum mask test. The duty cycle 
between Tx and Rx is nominally 50% and the transmit frame length is nominally 400 us. The adjacent chan- 
nel power is defined as the sum of the power measured in a 1 MHz band. For a pseudorandom data pattern, 
the adjacent channel power shall be a function of the offset between channel number N and the assigned 
transmitter channel M y where M is the actual transmitted center frequency and Wis a channel separated from 
it by an integer number of megahertz. 

Channel offset: 

|yV-A/]=2 -20 dBm or -40 dBc, whichever is the lower power. 
\N-M\>3 -40 dBm or -60 dBc, whichever is the lower power. 

The levels given, in dBc are. measured relative to the transmitter power measured in a I MHz channel 
centered on the transmitter center frequency. The adjacent channel power and the transmitter power for this 
subclause of the specification shall be measured with a resolution bandwidth of 100 kHz, a video bandwidth 
of 300 kHz, and a peak detector, and with the measurement device set to maximum hold. 

For any transmit center frequency M, two exceptions to the spectrum mask requirements are permitted 
within the operational frequency band, provided the exceptions are less than -50 dBc, where each offset 
channel exceeded counts as a separate exception. An exception occurs when the total energy within a given 
I MHz channel as defined in 14.6.5 exceeds the levels specified above. 
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14.6.1 4.5 Transmit center frequency tolerance 

The PMD transmit center frequency shall be within ±60 kHz of the nominal center frequency as specified in 
14.6.5. 

14.6.14.6 Transmitter ramp periods 

The transmitter shall go from off to within 2 dB of the nominal transmit power in 8 us or less. The transmit- 
ter shall go from within 2 dB of the nominal transmit power to off (less than -50 dBm) in 8 us or less. 

14.6.15 PMD receiver specifications 

The following portion of this subclause describes the receive functions and parameters associated with the 
PMD sublayer. In general, these are specified by primitives from the PLCP. The Receive PMD entity 
provides the actual means by which the signals required by the PLCP primitives are recovered from the 
medium. The PMD sublayer monitors signals on the medium and will return symbols from the set { { 1 },{0} } 
to the PLCP sublayer. 

14.6.15.1 Input signal range 

The PMD shall be capable of recovering a conformant PMD signal from the medium, as described in related 
subclauses, with a frame error ratio (FER) <3% for PSDUs of 400 octets generated with pseudorandom data, 
for receiver input signal levels in the range from -20 dBm to the receiver sensitivity (as specified in 
1 4.6. 1 5.4), across the frequency band of operation. 

14.6.15.2 Receive center frequency acceptance range 

An IEEE 802. 1 1 FHSS compliant PMD shall meet all specifications with an input signal having a center 
frequency range of ±60 kHz from nominal. 

14.6.15.3 CCA power threshold 

In the presence of any IEEE 802. 1 1 compliant 1 Mbit/s FH PMD signal above -85 dBm that starts synchro- 
nously with respect to slot times as specified in 14.3.3.2.1, the PHY shall signal busy, with a 90% probability of 
detection, during the preamble within the CCA assessment window. In the presence of any IEEE 802. 1 1 compli- 
ant 1 Mbit/s FH PMD signal above -85 dBm that starts asynchronously with respect to slot times as specified in 
14.3.3.2.1, the PHY shall signal busy, with a 70% probability of detection, during the preamble within the CCA 
window. In the presence of any IEEE 802. 1 1 compliant 1 Mbit/s FH PMD signal above -65 dBm, the PHY shall 
signal busy, with a 70% probability of detection, during random data within the CCA window. This specification 
applies to a PMD operating with a nominal EIRP of < 100 mW. A compliant PMD operating at a nominal output 
power greater than 100 mW shall use the following equation to define the CCA threshold, where P t represents 
transmit power. 

CCA threshold (preamble) » - 85 dBm - [5 x lo gio( 100 ^ w )] dBm 
CCA threshold (random data) = CCA threshold (preamble) + 20 dB 

14.6.15.4 Receiver sensitivity 

The sensitivity is defined as the minimum signal level required for an FER of 3% for PSDUs of 400 octets 
generated with pseudorandom data. The sensitivity shall be less than or equal to -80 dBm. The reference sensi- 
tivity is defined as -80 dBm for the 1 Mbit/s FH PHY specifications. 
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14.6.15.5 Intermodulation 

Intermodulation protection (IMp) is defined as the ratio of the minimum amplitude of one of two equal inter- 
fering signals to the desired signal amplitude, where the interfering signals are spaced 4 MHz and 8 MHz 
removed from the center frequency of the desired signal, both on the same side of center frequency. The IMp 
protection ratio is established at the interfering signal level that causes the FER of the receiver to be increased 
to 3% for PSDUs of 400 octets generated with pseudorandom data, when the desired signal is -77 dBm. Each 
interfering signal is modulated with the FH PMD modulation uncorrelated in time to each other or the desired 
signal. The PMD shall have the IMp for the interfering signal at 4 MHz and 8 MHz be >30 dB. 

1 4.6.1 5.6 Desensitization 

Desensitization (Dp) is defined as the ratio to measured sensitivity of the minimum amplitude of an interfer- 
ing signal that causes the FER at the output of the receiver to be increased to 3% for PSDUs of 400 octets 
generated with pseudorandom data, when the desired signal is -77 dBm. The interfering signal shall be 
modulated with the FHSS PMD modulation uncorrelated in time to the desired signal. The minimum Dp 
shall be as given in Table 46. The spectral purity of the interferer shall be sufficient to ensure that the 
measurement is limited by the receiver performance. 



Table 46—1 Mbit/s Dp 



Interferer frequency* 


Dp minimum 


M = N ±2 


30 dB 


M = N ± 3 or more 


40 dB 



a Where M is the interferer frequency and N is the desired channel frequency. 



14.6.15.7 Receiver radiation 

The signal leakage when receiving shall not exceed -50 dBm EIRP in the operating frequency range. The 
FHSS PHY shall conform with out-of-band spurious emissions by regulatory bodies. 

14.6.16 Operating temperature range 

Two temperature ranges for full operation compliance to the FH PHY are specified. Type I is defined as 0 °C 
to 40 °C and is designated for office environments. Type 2 is defined as -30 °C to +70 °C and is designated 
for industrial environments. 



14.7 FHSS PMD sublayer, 2.0 Mbit/s 
14.7.1 Overview 

This subclause details the RF specification differences of the optional 2 Mbit/s operation from the baseline 
1 Mbit/s PMD as contained in 14.6. Unless otherwise specified in this subclause, the compliant PMD shall 
also meet all requirements of 14.6 when transmitting at 2 Mbit/s. When implementing the 2 Mbit/s option, 
the preamble and PHY Header shall be transmitted at 1 Mbit/s. STAs implementing the 2 Mbit/s option shall 
also be capable of transmitting and receiving PPDUs at 1 Mbit/s. 
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14.7.2 Four-Level GFSK modulation 

For an FHSS 2 Mbit/s PMD, the modulation scheme shall be four-level Gaussian frequency shift keying 
(4GFSK), with a nominal symbol -period bandwidth product (BT) of 0.5. The four-level deviation factor, 
defined as the frequency separation of adjacent symbols divided by symbol rate, h4, shall be related to the 
deviation factor of the 2GFSK modulation, h2, by the following equation: 

h4/h2 = 0.45 ±0.01 

An incoming bit stream at 2 Mbit/s will be converted to 2-bit words or symbols, with a rate of Fclk = 
1 Msymbol/s. The first received bit will be encoded as the LMB of the symbol in Table 47. The bits will be 
encoded into symbols as shown in Table 47. 



Table 47 — Symbol encoding into carrier deviation 



1 Mbit/s, 2GFSK 


Symbol 


Carrier deviation 


1 


1/2 xh2x Fclk 


0 


-1/2 xh2x Fclk 


2 Mbit/s, 4GFSK 


Symbol 


Carrier deviation 


10 


3/2 x h4 x Fclk 


11 


1/2 x h4 x Fclk 


01 


-1/2 xh4x Fclk 


00 


-3/2 xh4x Fclk 


NOTE — These deviation values are measured using the 
center symbol of 7 consecutive symbols of the same value. 
The instantaneous deviation will vary due to Gaussian pulse 
shaping. 



The deviation factor h2 for 2GFSK (measured as the difference between frequencies measured in the middle 
of 0000 and 1111 patterns encountered in the SFD, divided by I MHz) will nominally be 0.32. The deviation 
factor h2 will be no less than 0.30 (with maximum dictated by regulatory bandwidth requirement). Accord- 
ingly, h4 (measured as a difference between the outermost frequencies, divided by 3, divided by 1 MHz) is 
nominally 0.45 x 0.32 = 0.144, and it will be no less than 0.45 x 0.3 = 0.135. 

The modulation error shall be less than ±15 kHz at the midsymbol time for 4GFSK, from the frequency 
deviations specified above, for a symbol surrounded by identical symbols, and less than ±25 kHz for any 
symbol. The deviation is relative to the actual center frequency of the RF carrier. For definition purposes, the 
actual center frequency is the midfrequency between symbols 1 1 and 0 1 . The actual center frequency shall 
be within ±60 kHz of the nominal channel center frequency defined in 14.6.5 and shall not vary by more 
than ±10 kHz/ms, from the start to end of the PPDU. The peak-to-peak variation of the actual center 
frequency over the PPDU shall not exceed 15 kHz. Symbols and terms used within this subclause are illus- 
trated in Figure 85. 
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. FREQUENCY 




Nom inal Center / 
Frequency 



Modulation Error 

► TIME 

Figure 85— Four-Level GFSK transmit modulation 

14.7.2.1 Frame structure for HS FHSS PHY 

The high rate FHSS PPDU consists of PLCP Preamble, PLCP Header, and whitened PSDU. The PLCP Pre- 
amble and PLCP Header format are identical to the 1 Mbit/s PHY, as described in 14.3.2. The whitened 
PSDU is transmitted in 2GFSK, 4GFSK, or potentially a higher-rate format, according to the rate chosen. 
The rate is indicated in a 3 -bit field in a PLCP Header, having a value of I or 2 bits/symbol (or Mbit/second). 

The PPDU is transmitted as four- level symbols, with the amount determined by number_of_symbols = 
(number_of_PSDU_octets x 8)/rate. 

The input bits are scrambled according to the method in 14.3.2.3. 

The scrambled bit stream is divided into groups of rate (1 or 2) consecutive bits. The bits are mapped into 
symbols according to Table 47. 

A bias suppression algorithm is applied to the resulting symbol stream. The bias suppression algorithm is 
defined in 14.3.2.3, Figure 72, and Figure 75. A polarity control symbol is inserted prior to each block of 
32 symbols (or less for the last block). The polarity control signals are 4GFSK symbols 10 or 00. The algo- 
rithm is equivalent to the case of 2GFSK, with the polarity symbol 2GFSK "I" replaced with 4GFSK 
symbol "10," and the 2GFSK polarity symbol "0" replaced with a 4GFSK symbol "00." 

14.7.3 Channel data rate 

The data rate for the whitened PSDU at the optional rate shall be 2.0 Mbit/s ± 50 ppm. 
14.7.3.1 Input dynamic range 

The PMD shall be capable of recovering a conformant PMD signal from the medium, as described in related 
subclauses, with an FER <3% for PSDUs of 400 octets generated with pseudorandom data, for receiver 
input signal levels in the range from -20 dBm to the receiver sensitivity (as specified in 14.7.3.2), across the 
frequency band of operation. 
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14.7.3.2 Receiver sensitivity 

The sensitivity is defined as the minimum signal level required for an FER of 3% for PSDUs of 400 octets 
generated with pseudorandom data. The sensitivity shall be less than or equal to -75 dBm. The reference 
sensitivity is defined as -75 dBm for the 2 Mbit/s FH PHY specifications. 

14.7.3.3 IMp 

IMp is defined as the ratio to -77 dBm of the minimum amplitude of one of the two equal-level interfering 
signals at 4 MHz and 8 MHz removed from center frequency, both on the same side of center frequency, that 
cause the FER of the receiver to be increased to 3% for PSDUs of 400 octets generated with pseudorandom 
data, when the desired signal is -72 dBm (3 dB above the specified sensitivity specified in 14.7.3.2). Each 
interfering signal is modulated with the FH 1 Mbit/s PMD modulation uncorrelated in time to each other or 
the desired signal. The FHSS optional 2 Mbit/s rate IMp shall be >25 dB. 

14.7.3.4 Dp 

Dp is defined as the ratio to measured sensitivity of the minimum amplitude of an interfering signal that 
causes the FER of the receiver to be increased to 3% for PSDUs of 400 octets generated with pseudorandom 
data, when the desired signal is -72 dB (3 dB above sensitivity specified in 14.7.3.2). The interfering signal 
shall be modulated with the FHSS PMD modulation uncorrelated in time to the desired signal. The mini- 
mum Dp shall be as given in Table 48. 



Table 48—2 Mbit/s Dp 



Interferer frequency 3 


DP minimum 


M = N±l 


20 dB 


M = N ± 3 or more 


30 dB 



Where M is the interferer frequency and N is the desired channel frequency. 



14.8 FHSS PHY management information base (MIB) 
14.8.1 Overview 

The following is the MIB for the FHSS PHY. 
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14.8.2 FH PHY attributes 

This subclause defines the attributes for the FHSS MIB. Table 49 lists these attributes and the default values. 
Following the table is a description of each attribute. 



Table 49 — FHSS PHY attributes 



Attribute 


Default value 


Operational 
semantics 


Operational behavior 


dotllPHYType 


FHSS = X'0r 


Static 


Identical for all FH PHYs 


dot I IRegDomainsSupported 


FCC=X'10* 
IC = X'20* 
ETSI = X*30' 
Spain = X'3l' 
France = X'32' 
MKiC = X'40' 


Static 


Implementation dependent 


dotl I CurrentReg Domain 


XW 


Dynamic LME 


Implementation dependent 


dot I ITempType 


Type I = X'Ol' 
Type 2 = X'02' 
Type 3 = X'03* 


Static 


Implementation dependent 


dotl lSupportedDataRatesTX 


1 Mbit/s = X'02' mandatory 

2 Mbit/s = X'04' optional 


Static 


Identical for all FH PHYs 


dotl lSupportedDataRatesRX 


1 Mbit/s = X'02' mandatory 

2 Mbit/s = X'04' optional 


Static 


Identical for all FH PHYs 


dot 1 1 SupportedTxAntennas 


Ant 1 =X*0r 
Ant 2 = X'02' 
Ant 3 = X'03' 
Ant n = n 


Static 


Implementation dependent 


dot 1 1 CurrentTxAntenna 


Ant 1 = default 


Dynamic LME 


Implementation dependent 


dotl lSupportedRxAntennas 


Ant I = X'0 1 ' 
Ant 2 = X'02* 
Ant 3 = X'03' 
Ant n = n 


Static 


Implementation dependent 


dot 1 1 Divers itySupport 


Available = X'0t' 
Not avail. = X'02' 
Control avail. = X'03' 


Static 


Implementation dependent 


dotl IDiversitySe lectio nRx 


Ant 1 =X'0r 
Ant 2 = X'02' 
Ant 3 = X'03' 
Ant 4 = X'04' 
Ant 5 = X'05* 
Ant 6 = X¥ 
Ant 7 = X'07* 
Ant 8 = XW 


Dynamic LME 


Implementation dependent 


dot 1 1 NumberSupportedPowerLevels 


Lvll = x'or 
Lvl2 = X:02* 
Lvl3 = X'03' 
Lvl4 = X'04' 
Lvl5 = X'05' 
Lvl6 = X*06' 
Lvl7 - X'OT 
Lvl8 = X'08' 


Static 


Implementation dependent 


dotl lTxPowerLevell 


Factory default 


Static 


Implementation dependent 


dotl !TxPowerLevel2 


Factory default 


Static 


Implementation dependent 


dotllTxPowerLevel3 


Factory default 


Static 


Implementation dependent 
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Table 4&— FHSS PHY attributes (continued) 



Attribute 


Default value 


Operational 
semantics 


Operational behavior 


dot! lTxPowerLevel4 


Factory def 


Static 


Implementation dependent 


dotl lTxPowerLeveI5 


Factory def. 


Static 


Implementation dependent 


dotl lTxPowerLevel6 


Factory def. 


Static 


Implementation dependent 


dotl !TxPowerLevel7 


Factory def. 


Static 


Implementation dependent 


dotUTxPowerLevel8 


Factory def. 


Static 


Implementation dependent 


dotl ICurrentTxPowerLevel 


T xP o we rLe ve 1 1 


Dvnamir I VIP 


uiipiciiiciiiduun ucpcnucm 


dotl IHopTime 


224 us 


Static 


Identical for all FH PHYs 


dot 1 1 CurrentChannelNumber 


X'OO' 


Dynamic PLME 




dotl IMaxDwellTime 


390 TU 


Static 


Regulatory domain dependent 


dotl lCurrentSet 


XW 


Dynamic PLME 




dotl ICurrentPattern 


XW 


Dynamic PLME 




dotl lCurrentlndex 


XW 


Dynamic PLME 




dotl ICurrentPowerState 


X'OToff 
X'02' on 


Dynamic LME 




NOTE — The column titled "Operational semantics" contains two types: static and dynamic. Static MIB attributes are 
fixed and cannot be modified for a given PHY implementation. MIB attributes defined as dynamic can be modified by 
some management entity. Whenever an attribute is defined as dynamic, the column also shows which entity has con- 
trol over the attribute. LME refers to the MAC sublayer management entity (MLME), while PHY refers to the physical 
layer management entity (PLME). 



14.8.2.1 FH PHY attribute definitions 

14.8.2.1.1 dotHPHYType 

The dotl IPHYType is FHSS. The LME uses this attribute to determine what PLCPand PMD are providing 
services to the MAC. It also is used by the MAC to determine what MAC sublayer management state 
machines must be invoked to support the PHY. The value of this attribute is defined as the integer 0 1 to indi- 
cate the FHSS PHY. 

14.8.2.1 .2 dotl 1 RegDomainsSupported 

Operational requirements for FHSS PHY are defined by agencies representing certain geographical regula- 
tory domains. These regulatory agencies may define limits on various parameters that differ from region to 
region. This parameters may include dotl lTxPower Levels, and dotl IMaxDwellTime, as well as the total 
number of frequencies in the hopping pattern. The values shown in Table 50 indicate regulatory agencies 
supported by this document. 

Since a PLCP and PMD might be designed to support operation in more than one regulatory domain, this 
attribute can actually represent a list of agencies. This list can be one or more of the above agencies and must 
be terminated using the null terminator. Upon activation of the PLCP and PMD, the information in this list 
must be used to set the value of the dotl lCurrentRegDomain attribute. 

14.8.2.1.3 dotl lCurrentRegDomain 

The dotl lCurrentRegDomain attribute for the FHSS PHY is defined as the regulatory domain under which 
the PMD is currently operating. This value must be one of the values listed in the 
dotl 1 RegDomainsSupported list. This MIB attribute is managed by the LME. 
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Table 50 — Regulatory domain codes 



Code point 


Regulatory agency 


Region 


X'lO' 


FCC 


United States 


X'20' 


IC 


Canada 


X'30' 


ETSI 


Most of Europe 


X'3l* 


Spain 


Spain 


X'32' 


France 


France 


X'40' 


MKJC 


japan 



1 4.8.2.1 A dot1 1 TempType 

The parameter dotl ITempType defines the temperature range supported by the PHY Type 1 equipment (X'01') 
supports a temperature range of 0 °C to 40 °C. Type 2 equipment <X'02') supports a temperature range of -20 °C 
to +55 °C. Type 3 equipment (X'03') supports a temperature range of -30 °C to +70 °C. 

14.8.2.1.5 dotHCurrentPowerState 

The dotl ICurrentPowerState attribute for the FHSS PHY allows the MAC sublayer management entity to 
control the power state of the PHY This attribute can be updated using the PLMESET.request. The permissi- 
ble values are ON and OFF. 

1 4.8.2.1 .6 dotl 1 SupportedDataRatesTX 

The dotl 1 SupportedDataRatesTX attribute for the FHSS PHY is defined as a null terminated list of supported 
data rates in the transmit mode for this implementation. Table 51 shows the possible values appearing in the 
list. 



Table 51— Supported data rate codes (dot11 SupportedDataRatesTX) 



Code point 


Data rate 


X'02' 


l Mbit/s 




2 Mbit/s 


xw 


Null terminator 



14.8.2.1.7 dotHSupportedDataRatesRX 

The dotl ISupportedDataRatesRX attribute for the FHSS PHY is defined as a null terminated list of supported 
data rates in the receive mode for this implementation. Table 52 shows the possible values appearing in the list. 



14.8.2.1.8 aMPDUMaxLength 

The aMPDUMaximumLength attribute for the FHSS PHY is defined as the maximum PSDU, in octets, that 
the PHY shall ever be capable of accepting. This value for the FHSS PHY is set at 4095 octets. The recom- 
mended value for maximum PSDU length in an FHSS PHY system is 400 octets at I Mbit/s and 800 octets 
at 2 Mbit/s which corresponds to a frame duration less than 3.5 ms. These values are optimized to achieve 
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Table 52— Supported data rate cod s (dotHSupportedDataRatesRX) 



Code point 


Data rate 


x'or 


I Mbit/s 


X'04' 


2 Mbit/s 


X'00' 


Null terminator 



high performance in a variety of RF channel conditions, particularly with respect to indoor multipath, chan- 
nel stability for moving STAs, and interference in the 2.4 GHz band. 

14.8.2.1.9 dotHSupportedTxAntennas 

The dotl 1 SupportedTxAntennas attribute for the FHSS PHY is defined as a null terminated list of antennas 
that this implementation can use to transmit data. Table 53 shows the possible values appearing in the list, 
where N< 255. 



Table 53 — Number of transmit antennas 



Code point 


Antenna number 


x*or 


Tx Antenna 1 


X'02' 


Tx Antenna 2 


X'03* 


Tx Antenna 3 






N 


Tx Antenna N 


xw 


Null terminator 



14.8.2.1.10 dotHCurrentTxAntenna 

The dotl lCurrentTxAntenna attribute for the FHSS PHY is used to describe the current antenna the imple- 
mentation is using for transmission. This value should represent one of the antennas appearing in the 
dotl 1 SupportedTxAntennas list. 

14.8.2.1.11 dotHSupportedRxAntenna 

The dotl lSupportedRxAntennas attribute for the FHSS PHY is defined as a null terminated list of antennas 
that this implementation can use to receive data. In the FHSS PHY primitives, one of these values is passed as 
part of the PHY-RXSTART.indicate to the MAC sublayer for every received packet. Table 54 shows the possi- 
ble values appearing in the list, where N< 255. 
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Table 54 — Number of receive antennas 



Code point 


Antenna number 


x'or 


Rx Antenna 1 


X'02* 


Rx Antenna 2 


X'03' 


Rx Antenna 3 






N 


Rx Antenna N 


X'00* 


Null terminator 



14.8.2.1.12 dotHDiversitySupport 

The dot 1 1 Diversity Support attribute for the FHSS PHY is used to describe the implementation's diversity 
support. Table 55 shows the possible values appearing in the list. 



Table 55 — Diversity support codes 



Code point 


Diversity support 


x'or 


Diversity available 


X'02' 


No diversity 




Control available 



The value X'OT indicates that this implementation uses two or more antennas for diversity. The value X'02' 
indicates that the implementation has no diversity support. The value X'03* indicates that the choice of anten- 
nas used during diversity is programmable. (See 14.8.2.1.13.) 

14.8.2.1 .13 dot1 1 DiversitySelectionRx 

The dot! 1 DiversitySelectionRx attribute for the FHSS PHY is a null terminated list describing the receive 
antenna or antennas currently in use during diversity and packet reception. Table 56 shows the possible val- 1 
ues appearing in the list, where /V< 255. 



Table 56 — Diversity select antenna codes 



Code point 


Antenna number 


x'or 


Rx Antenna 1 


X'02' 


Rx Antenna 2 


X'03' 


Rx Antenna 3 






N 


Rx Antenna N 




Null terminator 



The null terminated list can consist of one or more of the receive antennas listed in the 
dot I i Supported RxAntennas attribute. This attribute can be changed dynamically by the LME. 
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14.8.2.1 .14 dot1 1 NumberSupportedPowerLevels 

The dotl 1 NumberSupportedPowerLevels attribute for the FHSS PHY describes the number of power levels 
this implementation supports. This attribute can be an integer of value 1 through 8, inclusive. 

14.8.2.1.15 dot11TxPowerLevel1-8 

Some implementations may provide up to eight different transmit power levels. The dotl lTxPowerLevels 
attribute for the FHSS PHY is a list of up to eight power levels supported. Table 57 describes the list. 



Table 57 — Transmit power levels 



Attribute 


Power level 


TxPowerLevell 


Default setting 


TxPowerLevel2 


Level 2 


TxPowerLeveB 


Level 3 


TxPowerLevel4 


Level 4 


TxPowerLevel5 


Level 5 


TxPowerLevel6 


Level 6 


TxPowerLeveH 


Level 7 


TxPowerLevel8 


Level 8 



14.8.2.1 .16 dotl ICurrentTxPowerLevei 

The dotl ICurrentTxPowerLevei attribute for the FHSS PHY is defined as the current transmit output power 
level. This level shall be one of the levels implemented in the list of attributes called dotl 1 TxPowerLevell 
(where N is 1-8). This MIB attribute is also used to define the sensitivity of the CCA mechanism when the 
output power exceeds 100 mW. This MIB attribute is managed by the LME. 

14.8.2.1.17 dotHHopTime 

The dotl l HopTime attribute for the FHSS PHY describes the time allocated for the PHY to change to a new 
frequency. For the FHSS PHY, this time period is 224 us. 

14.8.2.1.18 dotHCurrentChannelNumber 

The dotllCurrentChannelNumber attribute for the FHSS PHY is defined as the current operating channel 
number of the PMD. The values of this attribute correspond to the values shown in Table 38. This MIB 
attribute is managed by the' PLME and is updated as the result of a PLMESET.request to dotl ICurrentSet, 
dotl lCurrentPattern, or dotl lCurrentlndex. 

14.8.2.1.19 dotHMaxDwellTime 

The dotl IMaxDwellTime attribute for the FHSS PHY is defined as the maximum time the PMD can dwell 
on a channel and meet the requirements of the current regulatory domain. For the FCC regulatory domain, 
this number is 390 TU (FCC = 400 ms). The recommended dwell time for the FHSS PHY is 19 TU. 
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14.8.2.1.20 dotHCurrentSet 

The FHSS PHY contains three sets of hopping patterns. The dotl lCurrentSet attribute for the FHSS PHY 
defines what set the STA is using to determine the hopping pattern. Its value can be I, 2, or 3. This attribute 
is managed by the PLME. 

14.8.2.1.21 dotHCurrentPattern 

There are up to 78 patterns in each hopping set used by the FHSS PHY. The dotl 1 CurrentPattern attribute 
for the FHSS PHY defines the x value used in Equation ( 1) in 14.6.8 to calculate the current channel number. 
Its value has various ranges, always within the overall range of 0 to 77, depending on the 
dotl lCurrentRegDomain. This attribute is managed by the PLME. 

14.8.2.1.22 dotHCurrentlndex 

The FHSS PHY addresses each channel in the selected hopping pattern through an index. The 
dotl ICurrentlndex attribute for the FHSS PHY defines the / value used in the equation for f x (i) in 14.6.8 to 
calculate the current channel number. Its value has various ranges, always within the overall range of 1 to 79, 
depending on the dotl lCurrentRegDomain. This attribute is managed by the PLME. 

1 4.8.2.1 .23 dotl 1 CurrentPowerState 

The parameter dot! I CurrentPowerState defines the operational state of the FHSS PHY When this attribute 
has a value of X'01\ the PHY is "OFF." When this attribute has a value of X'02\ the PHY is "ON." This 
attribute is managed by the PLME. 
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14.9 FH PHY characteristics 

Following are the static FH PHY characteristics, provided through the PLME-CHARACTERISTICS service 
primitive. The definitions of these characteristics are in 1 0.4.3. 



Table 57a— FH PHY characteristics 



Characteristic 


Value 


Notes 


aSlotTime 


50 ps 


— 


aSIFSTime 


28 jas 


In order to account for variations between implementations, this 
value has a tolerance as specified in 9.2.3.1. 


aCCATime 


27 us 


This period includes the aRxRFDelay and the aRxPLCPDelay. 


aRxTxTumaroundTime 


20 ps 




aTxPLCPDelay 


l^s 


Implementors may choose to increase or decrease this delay as long 
as the requirements of aRxTxTumaroundTime are met. 


aRxPLCPDelay 


2 us 


Implementors may choose to increase or decrease this delay as long 
as the requirements of aSIFSTime and aCCATime are met. 


aRxTxSwitchTime 


lOps 


Implementors may choose to increase or decrease this delay as long 
as the requirements of aRxTxTumaroundTime are met. 


aTx Ra m pO nT im e 


8 ps 


Implementors may choose to increase or decrease this delay as long 
as the requirements of aRxTxTumaroundTime are met. 


aTxRampOrfTime 


8ps 




aTxRFDelay 


l fiS 


Implementors may choose to increase or decrease this delay as long 
as the requirements of aRxTxTumaroundTime are met. 


aRxRFDelay 


4 ps 


Implementors may choose to increase or decrease this delay as long 
as the requirements of aSIFSTime and aCCATime are met. 


aAirPropagationTirae 


l ps 


Variations in the actual propagation time are accounted for in the 
allowable range of aSIFSTime. 


aMACProcessingDelay 


2 ps 


Implementors may choose to increase or decrease this delay as long 
as the requirements of aSIFSTime are met. 


aPreamble Length 


96 ps 




aPLCPHeaderLength 


32 ps 




aM P D U DurationFactor 


31250000 


This factor is calculated as [(33/32) -I] x 10 9 to account for the 
expansion due to the data whitener encoding algorithm. 


aMPDUMaxLength 


4095 


The recommended value for maximum PSDU length in an FHSS 
PHY system is 400 octets at 1 Mbit/s and 800 octets at 2 Mbit/s, 
which corresponds to a frame duration less than 3.5 ms. These val- 
ues are optimized to achieve high performance in a variety of RF 
channel conditions, particularly with respect to indoor multipath, 
channel stability for moving STAs, and interference in the 2.4 GHz 
band. 


aCWmin 


15 




aCWmax 


1023 
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15. Direct sequence spread spectrum (DSSS) PHY specification for the 
2.4 GHz band designated for ISM applications 

15.1 Overview 

The PHY for the direct sequence spread spectrum (DSSS) system is described in this clause. The RF LAN 
system is initially aimed for the 2.4 GHz band designated for ISM applications as provided in the USA 
according to FCC 15.247, in Europe by ETS 300-328, and in other countries according to 15.4.6.2. 

The DSSS system provides a wireless LAN with both a 1 Mbit/s and a 2 Mbit/s data payload communication 
capability. According to the FCC regulations, the DSSS system shall provide a processing gain of at least 
10 dB. This shall be accomplished by chipping the baseband signal at 1 1 MHz with an 1 1 -chip PN code. The 
DSSS system uses baseband modulations of differential binary phase shift keying (DBPSFC) and differential 
quadrature phase shift keying (DQPSK) to provide the I Mbit/s and 2 Mbit/s data rates, respectively. 

15.1.1 Scope 

The PHY services provided to the IEEE 802.11 wireless LAN MAC by the 2.4 GHz DSSS system are 
described in this clause. The DSSS PHY layer consists of two protocol functions: 

a) A physical layer convergence function, which adapts the capabilities of the physical medium depen- 
dent (PMD) system to the PHY service. This function shall be supported by the physical layer 
convergence procedure (PLCP), which defines a method of mapping the IEEE 802.11 MAQ^ 
sublayer protocol data units (MPDU) into a framing format suitable for sending and receiving user 
data and management information between two or more STAs using the associated PMD system. 

b) A PMD system, whose function defines the characteristics of, and method of transmitting and 
receiving data through, a wireless medium (WM) between two or more STAs each using the DSSS 
system. 

1 5.1 .2 DSSS PHY functions 

The 2.4 GHz DSSS PHY architecture is depicted in the reference model shown in Figure II. The DSSS 
PHY contains three functional entities: the PMD function, the physical layer convergence function, and the 
layer management function. Each of these functions is described in detail in the following subclauses. 

The DSSS PHY service shall be provided to the MAC through the PHY service primitives described in 
Clause 12. 

15.1.2.1 PLCP sublayer 

To allow the IEEE 802.1 1 MAC to operate with minimum dependence on the PMD sublayer, a physical 
layer convergence sublayer is defined. This function simplifies the PHY service interface to the IEEE 802. 1 1 
MAC services. 

15.1.2.2 PMD sublayer 

The PMD sublayer provides a means to send and receive data between two or more STAs. This clause is 
concerned with the 2.4 GHz ISM bands using direct sequence modulation. 

15.1.2.3 Physical layer management entity (PLME) 

The PLME performs management of the local PHY functions in conjunction with the MAC management 
entity. 
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15.1.3 Service specification m thod and notation 

The models represented by figures and state diagrams are intended to be illustrations of functions provided. 
It is important to distinguish between a model and a real implementation. The models are optimized for 
simplicity and clarity of presentation; the actual method of implementation is left to the discretion of the 
IEEE 802. 11 DSSS PHY compliant developer. 

The service of a layer or sublayer is a set of capabilities that it offers to a user in the next-higher layer (or 
sublayer). Abstract services are specified here by describing the service primitives and parameters that char- 
acterize each service. This definition is independent of any particular implementation. 

15.2 DSSS PLCP sublayer 

15.2.1 Overview 

This clause provides a convergence procedure in which MPDUs are converted to and from PPDUs. During 
transmission, the MPDU shall be prepended with a PLCP Preamble and Header to create the PPDU. At the 
receiver, the PLCP Preamble and header are processed to aid in demodulation and delivery of the MPDU. 

15.2.2 PLCP frame format 

Figure 86 shows the format for the PPDU including the DSSS PLCP Preamble, the DSSS PLCP Header, and 
the MPDU. The PLCP Preamble contains the following fields: Synchronization (Sync) and Start Frame 
Delimiter (SFD). The PLCP Header contains the following fields: IEEE 802.11 Signaling (Signal), IEEE 
802.11 Service (Service), LENGTH (Length), and CCITT CRC-16. Each of these fields is described in 
detail in 15.2.3. 



SYNC 


SFD 


SIGNAL 


SERVICE 


LENGTH 


CRC 


128 bits 


16 bits 


8 bits 


8 bits 


16 bits 


16 bits 



PLCP Preamble 
144 bits 


PLCP Header 
48 bits 


MPDU 






PPDU 





Figure 86 — PLCP frame format 



1 5.2.3 PLCP field definitions 

The entire PLCP Preamble and Header shall be transmitted using the 1 Mbit/s DBPSK modulation described 
in 1 5.4.7. All transmitted bits shall be scrambled using the feedthrough scrambler described in 15.2.4. 

15.2.3.1 PLCP Synchronization (SYNC) field 

The SYNC field shall consist of 1 28 bits of scrambled ones. This field shall be provided so that the receiver 
can perform the necessary operations for synchronization. 
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15.2.3.2 PLCP Start Frame Delimiter (SFD) 

The SFD shall be provided to indicate the start of PHY- dependent parameters within the PLCP Preamble. 
The SFD shall be a 1 6-bit field, XT3A0' (msb to Isb). The Isb shall be transmitted first in time. 

15.2.3.3 PLCP IEEE 802.11 Signal (SIGNAL) field 

The 8-bit IEEE 802.1 1 signal field indicates to the PHY the modulation that shall be used for transmission 
(and reception) of the MPDU. The data rate shall be equal to the signal field value multiplied by 100 kbit/s. 
The DSSS PHY currently supports two mandatory modulation services given by the following 8-bit words, 
where the Isb shall be transmitted first in time: 

a) X'OA' (msb to Isb) for I Mbit/s DBPSK 

b) X'14' (msb to Isb) for 2 Mbit/s DQPSK 

The DSSS PHY rate change capability is described in 15.2.5. This field shall be protected by the CCITT 
CRC-16 frame check sequence described in 15.2.3.6. 

15.2.3.4 PLCP IEEE 802.11 Service (SERVICE) field 

The 8-bit IEEE 802. 1 1 service field shall be reserved for future use. The value of X'00' signifies IEEE 802. 1 1 
device compliance. The Isb shall be transmitted first in time. This field shall be protected by the CCITT 
CRC-16 frame check sequence described in 1 5.2.3.6. l 

15.2.3.5 PLCP Length (LENGTH) field 

The PLCP Length field shall be an unsigned 1 6-bit integer that indicates the number of microseconds ( 16 to 
2 l6 -l as defined by aMPDUMaxLength) required to transmit the MPDU. The transmitted value shall be 
determined from the LENGTH parameter in the TXVECTOR issued with the PH Y-TX START.req uest prim- 
itive described in 12.3.5.4. The length field provided in the TXVECTOR is in bytes and is converted to 
microseconds for inclusion in the PLCP LENGTH field. The Isb shall be transmitted first in time. This field 
shall be protected by the CCITT CRC-16 frame check sequence described in 15.2.3.6. 

15.2.3.6 PLCP CRC (CCITT CRC-16) field 

The IEEE 802. 1 1 SIGNAL, IEEE 802.1 1 SERVICE, and LENGTH fields shall be protected with a CCITT 
CRC-16 frame check sequence (FCS). The CCITT CRC-16 FCS shall be the one's complement of the 
remainder generated by the modulo 2 division of the protected PLCP fields by the polynomial: 

jc 16 + jc 12 +jc 5 + 1 

The protected bits shall be processed in transmit order. All FCS calculations shall be made prior to data 
scrambling. 

As an example, the SIGNAL, SERVICE, and LENGTH fields for a DBPSK signal with a packet length of 
1 92 us (24 bytes) would be given by the following: 

0101 0000 0000 0000 0000 001 1 0000 0000 (leftmost bit transmitted first in time) 

The one's complement FCS for these protected PLCP Preamble bits would be the following: 
0101101101010111 (leftmost bit transmitted first in time) 

Figure 87 depicts this example. 
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Transmit and Receive PLCP Header 
CCITT CRC-16 Calculator 



Serial Data 


CCITT 


Serial Data 


Input 


CRC-16 


Output 




l 


I 








Preset to 
ones 



1 ) Preset to all ones 

2) Shift signal, service, length fields 
Through the shift register 

3) Take one's complement of remainder 

4) Transmit out serial msb first 



CCITT CRC-16 Polynomial: G(x) = X + X + X + 1 



Serial Data Input 




(msb first) 



Figure 87— CCITT CRC-16 implementation 



An illustrative example of the CCITT CRC-16 FCS using the information from Figure 87 follows in Figure 88. 

Data CRC registers 

msb Isb 

1111111111111111 ; initialize preset to Vs 

0 1110111111011111 

1 1101111110111110 
0 1010111101011101 

> 1 0101111010111010 

0 1011110101110100 

0 0110101011001001 

0 1101010110010010 

0 1011101100000101 

0 0110011000101011 

0 1100110001010110 

0 1000100010001101 

0 0000000100111011 

0 0000001001110110 

0 0000010011101100 

0 0000100111011000 

0 0001001110110000 

0 0010011101100000 

0 0100111011000000 

0 1001110110000000 

0 0010101100100001 

0 0101011001000010 

0 1010110010000100 

1 0101100100001000 
1 1010001000110001 
0 6101010001000011 
0 1010100010000110 
0 0100000100101101 
0 1000001001011010 
0 0001010010010101 
0 0010100100101010 
0 0101001001010100 
0 1010010010101000 

0101101101010111 ; one's complement, result = CRC FCS parity 

Figure 88 — Example CRC calculation 
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1 5.2.4 PLCP/DSSS PHY data scrambler and descrambler 

The polynomial G(z) = z" 1 + z" 4 + 1 shall be used to scramble all bits transmitted by the DSSS PHY. The 
feedthrough configuration of the scrambler and descrambler is self-synchronizing, which requires no prior 
knowledge of the transmitter initialization of the scrambler for receive processing. Figure 89 and Figure 90 
show typical implementations of the data scrambler and descrambler, but other implementations are possible. 

The scrambler should be initialized to any state except all ones when transmitting. 



Scrambler Polynomial; G(z)=Z" r + Z 4 + 1 



Serial Data In. 



XOR 

— 



Serial Data Out t 





r-r r 




w 



■XOR«- 



Figure 89 — Data scrambler 



Descrambler Polynomial; G(z)=Z 7 + Z 4 + 1 
Serial Data In 



z z 2 r t 



XOR 



rz 6 r 



xor{<- 



.SeriaJ.Data.Out, 



Figure 90 — Data descrambler 



15.2.5 PLCP data modulation and modulation rate change 

The PLCP Preamble shall be transmitted using the I Mbit/s DBPSK modulation. The IEEE 802. 1 1 SIGNAL 
field shall indicate the modulation that shall be used to transmit the MPDU. The transmitter and receiver 
shall initiate the modulation indicated by the IEEE 802. 1 1 SIGNAL field starting with the first symbol ( I bit 
for DBPSK or 2 bits for DQPSK) of the MPDU. The MPDU transmission rate shall be set by the DATA- 
RATE parameter in the TXVECTOR issued with the PHY-TXSTART. request primitive described in 
1 5.4.4. 1. 

15.2.6 PLCP transmit procedure 

The PLCP transmit procedure is shown in Figure 91. 

In order to transmit data, PHY-TXSTART. request shall be enabled so that the PHY entity shall be in the 
transmit state. Further, the PHY shall be set to operate at the appropriate channel through station manage- 
ment via the PLME. Other transmit parameters such as DATARATE, TX antenna, and TX power are set via 
the PHY-SAP with the PHY-TXSTART.request(TX VECTOR) as described in 15.4.4.2. 
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PMD_DATA.req 
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/ SYNC 


SFD 
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MPDU 
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I I 











Scramble start 
TX Power RAMP 



CRC16 
start 



CRC 1 6 Rate change start 
end 



TX Power 
RAMP Off 



Figure 91 — PLCP transmit procedure 



Based on the status of clear channel assessment (CCA) indicated by PHY-CC A. indicate, the MAC will assess 
that the channel is clear. A clear channel shall be indicated by PHY-CCA.indicate(IDLE). If the channel is 
clear, transmission of the PPDU shall be initiated by issuing the PHY-TXSTART.request (TXVECTOR") primi- 
tive. The TXVECTOR elements for the PHY-TXSTART.request are the PLCP Header parameters SIGNAL 
(DATARATE), SERVICE, and LENGTH, and the PMD parameters of TX_ANTENN A and TXPWR_LEVEL. 
The PLCP Header parameter LENGTH is calculated from the TXVECTOR element by multiplying by 8 for 
1 Mbit/s and by 4 for 2 Mbit/s. 

The PLCP shall issue PMD_ANTSEL, PMD_RATE, and PMD_TXPWRLVL primitives to configure the PHY. 
The PLCP shall then issue a PMD_TXSTART.request and the PHY entity shall immediately initiate data 
scrambling and transmission of the PLCP Preamble based on the parameters passed in the PHY- 
TXSTART.request primitive. The time required for TX power-up ramp described in 15.4.7.7 shall be included 
in the PLCP synchronization field. Once the PLCP Preamble transmission is complete, data shall be exchanged 
between the MAC and the PHY by a series of PHY-DATA.request(DATA) primitives issued by the MAC and 
P H Y- DATA. confirm primitives issued by the PHY. The modulation rate change, if any, shall be initiated with 
the first data symbol of the MPDU as described in 15.2.5. The PHY proceeds with MPDU transmission 
through a series of data octet transfers from the MAC. At the PMD layer, the data octets are sent in Isb to msb 
order and presented to the PHY layer through PMD_DATA. request primitives. Transmission can be prema- 
turely terminated by the MAC through the primitive PHY-TXEND.request. PHY-TXSTART shall be disabled 
by the issuance of the PHY-TXEND.request. Normal termination occurs after the transmission of the final bit 
of the last MPDU octet according to the number supplied in the DSSS PHY preamble LENGTH field. The 
packet transmission shall be completed and the PHY entity shall enter the receive state (i.e., PHY-TXSTART 
shall be disabled). It is recommended that chipping continue during power-down. Each PHY-TXEND.request 
is acknowledged with a PHY-TXEND.confirm primitive from the PHY. 

A typical state machine implementation of the PLCP transmit procedure is provided in Figure 92. 
15.2.7 PLCP receive procedure 



The PLCP receive procedure is shown in Figure 93. 



In order to receive data, PHY-TXSTART.request shall be disabled so that the PHY entity is in the receive 
state. Further, through station management via the PLME, the PHY is set to the appropriate channel and the 
CCA method is chosen. Other receive parameters such as receive signal strength indication (RSSI), signal 
quality (SQ), and indicated DATARATE may be accessed via the PHY-SAP. 



200 



Copyright © 1999 IEEE. All rights reserved. 



ISO/IEC 8802-11: 1999(E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.11, 1999 Edition 



PHY_TXSTART.request(TXVECTOR) 



Initialize 



PMD_TXPWRLVL.req 
PMD_ANTSELreq 



TX SYNC PATTERN 


PMD.RATE 
PMD.TXS 
TX 128 sc 


.req (08PSK) 
TART.req 
rambled t's 



TX PLCP DATA 



TX 1 6 bit SFD 
TX 8 bit SIGNAL 
TX 8 bit SERVICE 
TX 16 bit LENGTH 
TX 16bitCRC 



SETUP MPDU TX 



if RATE = DQPSK 
PMD.RATE.req (DQPSK) 

set Length count 



TX MPDU OCTET 



PHY_DATA.req(DATA) 
get octet from MAC 
Set Octet bit count 



TX SYMBOL 



PMD_DATA.req 



Decrement Bit 



decrement bit count 
by bits per symbol 



bit count <> 0 



bit count = 0 



Decrement Length 



decrement length count 



lengthoO 



length = 0 



Switch to RX STATE 



0„ 



any stage in the above flow diagram, if a PHY_THEND. Request is received. 



Figure 92— PLCP transmit state machine 
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PHY_CCA.ind(BUSY) 

PHY_RXSTART.ind(RXVECTOR) 
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PHY 
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MPDU 



t.t 
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Figure 93— PLCP rec ive pr cedure 
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Upon receiving the transmitted energy, according to the selected CCA mode, the PMD_ED shall be enabled 
(according to 15.4.8.4) as the RSSI strength reaches the ED.THRESHOLD and/or PMD_CS shall be 
enabled after code lock is established. These conditions are used to indicate activity to the MAC via PHY- 
CCA.indicate according to 15.4.8.4. PHY-CCA.indicate(BUSY) shall be issued for energy detection and/or 
code lock prior to correct reception of the PLCP frame. The PMD primitives PMD_SQ and PMD_RSSI are 
issued to update the RSSi and SQ parameters reported to the MAC. 

After PHY-CCA.indicate is issued, the PHY entity shall begin searching for the SFD field. Once the SFD 
field is detected, CCITT CRC-16 processing shall be initiated and the PLCP IEEE 802.1 1 SIGNAL, IEEE 
802.11 SERVICE and LENGTH fields are received. The CCITT CRC-16 FCS shall be processed. If the 
CCITT CRC-16 FCS check fails, the PHY receiver shall return to the RX Idle state as depicted in Figure 94. 
Should the status of CCA return to the IDLE state during reception prior to completion of the full PLCP 
processing, the PHY receiver shall return to the RX Idle state. 

If the PLCP Header reception is successful (and the SIGNAL field is completely recognizable and 
supported), a PHY-RXSTART.indicate(RXVECTOR) shall be issued. The RXVECTOR associated with this 
primitive includes the SIGNAL field, the SERVICE field, the MPDU length in bytes (calculated from the 
LENGTH field in microseconds), the antenna used for receive (RX_ ANTENNA), RSSI, and SQ. 

The received MPDU bits are assembled into octets and presented to the MAC using a series of PHY- 
DATA.indicate(DATA) primitive exchanges. The rate change indicated in the IEEE 802.11 SIGNAL field 
shall be initiated with the first symbol of the MPDU as described in 15.2.5. The PHY proceeds with MPDU 
reception. After the reception of the final bit of the last MPDU octet indicated by the PLCP Preamble 
LENGTH field, the receiver shall be returned to the RX Idle state as shown in Figure 94. A PHY- 
RXEND.indicate(NoError) primitive shall be issued. A PHY-CCA.indicate(IDLE) primitive shall be issued 
following a change in PHYCS (PHY carrier sense) and/or PHYED (PHY energy detection) according to the 
selected CCA method. 

In the event that a change in PHYCS or PHYED would cause the status of CCA to return to the IDLE state 
before the complete reception of the MPDU as indicated by the PLCP LENGTH field, the error condition 
PHY-RXEND.indicate(CarrierLost) shall be reported to the MAC. The DSSS PHY will ensure that the CCA 
will indicate a busy medium for the intended duration of the transmitted packet. 

If the PLCP Header is successful, but the indicated rate in the SIGNAL field is not receivable, a PHY- 
RXSTART.indicate will not be issued. The PHY shall issue the error condition PHY-RXEND.indi- 
cate(UnsupportedRate). If the PLCP Header is successful, but the SERVICE field is out of IEEE 802. 1 1 
DSSS specification, a PHY-RXSTART. indicate will not be issued. The PHY shall issue the error condition 
PHY-RXEND.indicate(FormatViolation). Also, in both cases, the DSSS PHY will ensure that the CCA shall 
indicate a busy medium for the intended duration of the transmitted frame as indicated by the Length field. 
The intended duration is indicated by the Length field (length x 1 us). 

A typical state machine implementation of the PLCP receive procedure is provided in Figure 94. 
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Figure 94 — PLCP receive state machine 



15.3 DSSS physical layer management entity (PLME) 
15.3.1 PLME_SAP sublayer management primitives 

Table 58 lists the MIB attributes that may be accessed by the PHY sublayer entities and intralayer of higher- 
layer management entities (LMEs). These attributes are accessed via the PLME-GET, PLME-SET, and 
PLME-RESET primitives defined in Clause 10. 
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15.3.2 DSSS PHY MIB 

All DSSS PHY MIB attributes are defined in Clause 12, with specific values defined in Table 58. 



Table 58 — MIB attribute default values/ranges 



Managed object 


Default value/range 


Operational 
semantics 


dot 1 1 PhyOperarionComplianceG roup 


dot II P H Ydot It TempType 


DSSS-2.4 (02) 


Static 


dot 1 1 TempType 


Implementation dependent 


Static 


dot 1 1 RegDomainsSupported 


Implementation dependent 


Static 


dotl ICurrentRegDomain 


Implementation dependent 


Static 


d ot 11 P hy Ra teGrou p 


dotl ISupportedDataRatesTx 


X'02\ X'04' 


Static 


dotl ISupportedData Rates Rx 


X'02\ XW 


Static 


dotl lPhyAntennaComplianceGroup 


dotl ICurrentTxAntenna 


Implementation dependent 


Dynamic 


dotl IDiversitySupport 


Implementation dependent 


Static 


dotl 1 Current RxAntenna 


Implementation dependent 


Dynamic 


dot llPhyTxPowerComplianceG roup 


dotl INumberSupportedPowerLevels 


Implementation dependent 


Static 


dotl lTxPowerLevell 


Implementation dependent 


Static 


dotl lTxPowerLevel2 


Implementation dependent 


Static 


dotl ITxPowerLeveB 


Implementation dependent 


Static 


dotl lTxPowerLevel4 


Implementation dependent 


Static 


dotl lTxPowerLevel5 


Implementation dependent 


Static 


dotl lTxPowerLevel6 


Implementation dependent 


Static 


dotl lTxPowerLeve!7 


implementation dependent 


Static 


dotllTxPowerLeve!8 


Implementation dependent 


Static 


dotl ICurrentTxPowerLevel 


Implementation dependent 


Dynamic 


dotl lPhyDSSSComplianceG roup 


dotl lCurrentChannel 


Implementation dependent 


Dynamic 


dotl lCCAModeSupported 


Implementation dependent 


Static 


dotl lCurrentCCAMode 


Implementation dependent 


Dynamic 


dotllEDThreshold 


Implementation dependent 


Dynamic 


dotl 1 Ante nnasLisrG roup 


dotl ISupportedTxAntenna 


Implementation dependent 


Static 


dotl lSupportedRx Antenna 


Implementation dependent 


Static 


dot 1 1 DiversitySelectionRx 


Implementation dependent 


Dynamic 


NOTE — The column titled "Operational semantics" contains two types: static and dynamic. 
Static MIB attributes are fixed and cannot be modified for a given PHY implementation. 
MIB attributes defined as dynamic can be modified by some management entities. 
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15.3.3 DS PHY characteristics 

The static DS PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, 
are shown in Table 59. The definitions of these characteristics are in 1 0.4.3. 



Table 59 — DS PHY characteristics 



Characteristic 


Value 


aSlotTime 


20 us 


aSIFSTime 


10 us 


aCCATime 


<L5us 


a RxTxTumaroundTime 


<5 us 


aTxPLCPDelay 


Implementors may choose any value for this delay as long 
as the requirements of a RxTxTumaroundTime are met. 


aRxPLCPDelay 


Implementors may choose any value for this delay as long 
ti» uic icijuiiciucnis oi aoiro (line anu ai_i_/\iime are met. 


aRxTxSwitchTime 




aTx RamnOn l imp 


iiiipiciiicNiura may ciiuuse any value ior mis ueiay as long 
as the requirements of a RxTxTumaroundTime are met. 


aTxRampOftTirne 


Implementors may choose any value for this delay as long 
as the requirements of aSIFSTime are met. 


aTxRF Delay 


ijnjjic.iiic.uiui a may ciiuuac aixy vaiuc in la ueiay lib long 

as the requirements of a RxTxTumaroundTime are met. 


aRxRfDelay 


Implementors may choose any value for this delay as long 
as the requirements of aSIFSTime and aCCATime are met. 


aAirPropagationTime 


lus 


aMACProcessingDelay 


0 (not applicable) 


aPreambleLength 


144 ^s 


aPLCPHeaderLength 


48 us 


aMPDUDurationFactor 


0 


aMPDUMaxLength 


4<x<<2 13 - 1) 


aCWrain 


31 


aCWmax 


1023 



15.4 DSSS PMD sublayer 

15.4.1 Scope and field of application 

This subclause describes the PMD services provided to the PLCP for the DSSS PHY. Also defined in this 
subclause are the functional, electrical, and RF characteristics required for interoperability of implementa- 
tions conforming to this standard. The relationship of this standard to the entire DSSS physical layer is 
shown in Figure 95. 
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Figure 95 — PMD layer reference model 



15.4.2 Overview of service 

The DSSS PMD sublayer accepts PLCP sublayer service primitives and provides the actual means by which 
data shall be transmitted or received from the medium. The combined function of DSSS PMD sublayer 
primitives and parameters for the receive function results in a data stream, timing information, and associ- 
ated received signal parameters being delivered to the PLCP sublayer. A similar functionality shall be 
provided for data transmission. 

1 5.4.3 Overview of interactions 

The primitives associated with the IEEE 802. II PLCP sublayer to the DSSS PMD fall into two basic 
categories: 

a) Service primitives that support PLCP peer-to-peer interactions, and 

b) Service primitives that have local significance and that support sublayer-to-sublayer interactions. 

15.4.4 Basic service and options 

All of the service primitives described in this clause are considered mandatory unless otherwise specified. 
15.4.4.1 PMD_SAP peer-to-peer service primitives 

Table 60 indicates the primitives for peer-to-peer interactions. 



Table 60 — PMD.SAP peer-to-peer service primitives 



' Primitive 


Request 


Indicate 


Confirm 


Response 


PHY-RXSTART 




X 






PHY-RXEND 




X 






PHY-CCA 




X 






PHY-TXSTART 


X 




X 




PHY-TXEND 


X 




X 




PHY-DATA 


X 


X 


X 
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15.4.4.2 PMD_SAP peer-to-peer service primitive parameters 

Several service primitives include a parameter vector. This vector shall be a list of parameters that may vary 
depending on PHY type. Table 61 indicates the parameters required by the MAC or DSSS PHY in each of 
the parameter vectors used for peer-to-peer interactions. 



Table 61— DSSS PMD_SAP peer-to-peer service primitives 



Parameter 


Associated primitive 


Value 


LENGTH 


RXVECTOR, TXVECTOR 


0 to 2 13 - 1 


DATARATE 


RXVECTOR, TXVECTOR 


1, 2Mbit/s 


SERVICE 


RXVECTOR, TXVECTOR 


l,2Mbit/s 


TXPWR_LEVEL 


TXVECTOR 


I, 2 Mbit/s 


TX.ANTENNA 


TXVECTOR 


1,2 Mbit/s 


RSSI 


RXVECTOR 


1,2 Mbit/s 


SQ 


RXVECTOR 


1,2 Mbit/s 


RX.ANTENNA 


RXVECTOR 


1,2 Mbit/s 



15.4.4.3 PMD_SAP sublayer-to-sublayer service primitives 

Table 62 indicates the primitives for sublayer-to-sublayer interactions. 



Table 62 — PMD_SAP sublayer-to-sublayer service primitives 



Primitive 


Request 


Indicate 


Confirm 


Response 


PMD_TXSTART 


X 








PMD_TXEND 


X 








PMD_ANTSEL 


X 


X 






PMD.TXPWRLVL 


X 








PMD_RATE 


X 


X 






PMD.RSSI 




X 






PMD.SQ 




X 






PMD_CS 




X 






PMD_ED 


X 


X 
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15.4.4.4 PMD_SAP service primitive parameters 



Table 63 indicates the parameters for the PMD primitives. 



Table 63 — List of parameters for the PMD primitives 



Parameter 


Associate primitive 


Value 


DATA 


PHY-DATA. request 
PHY- DATA, indicate 


Octet value: XW-X'FF* 


TXVECTOR 


PHY-DATA reauest 


A cpt nt~ nara m**tprc 

j\ 3tl \J1 pill a I licit 1 a 


RXVECTOR 


PHY-DATA.indicate 


A set of parameters 


TXDJJNIT 


PMD_DATA.request 


One(l), Zero{0): DBPSiC 
dibit combinations 
00,01,11,10: DQPSK 


RXD_UNIT 


PMD_DATA.indicate 


One(l), Zero(0): DBPSIC 
dibit combinations 
00,01,11,10: DQPSK 


RF_STATE 


PMD_TXE.request 


Receive, Transmit 


ANT_STATE 


PMD_ANTSEL.indicate 
PMD_ANTSEL.request 


1 to 256 


TXPWR_LEVEL 


PHY-TX START 


0, 1,2, 3 (max of 4 levels) 


RATE 


PMD_RATE.indicate 
PMD_RATE. request 


X'OA* for 1 Mbit/s DBPSK 
X' 14' for 2 Mbit/s DQPSK 


RSSI 


PMD_RSSl.indicate 


0-8 bits of RSSI 


SQ 


PMD_SQ.indicate 


0-8 bits of SQ 



15.4.5 PMD_SAP detailed service specification 

The following subclauses describe the services provided by each PMD primitive. 
15.4.5.1 PMD_DATA.request 

15.4.5.1.1 Function 

This primitive defines the transfer of data from the PLC P sublayer to the PMD entity. 

15.4.5.1.2 Semantics of the service primitive 

The primitive shall provide "the following parameter: 

PMD_DATA.request(TXD_UNIT) 

The TXDJJNIT parameter takes on the value of either one( l) or zero(0) for DBPSK modulation or the dibit 
combination 00, 01, 1 1, or 10 for DQPSK modulation. This parameter represents a single block of data, 
which, in turn, shall be used by the PHY to be differentially encoded into a DBPSK or DQPSK transmitted 
symbol. The symbol itself shall be spread by the PN code prior to transmission. 
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15.4.5.1.3 When generated 

This primitive shall be generated by the PLCP sublayer to request transmission of a symbol. The data clock 
for this primitive shall be supplied by the PMD layer based on the PN code repetition. 

15.4.5.1.4 Effect of receipt 

The PMD performs the differential encoding, PN code modulation, and transmission of the data. 

15.4.5.2 PMD_DATA.indicate 

15.4.5.2.1 Function 

This primitive defines the transfer of data from the PMD entity to the PLCP sublayer. 

15.4.5.2.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD_DATA.indicate(RXD_UNIT) 

The RXD_UNIT parameter takes on the value of one (1) or zero (0) for DBPSK modulation or as the dibit 
00, 01, 1 1, or 10 for DQPSK modulation. This parameter represents a single symbol that has been demodu- 
lated by the PMD entity. 

15.4.5.2.3 When generated 

This primitive, which is generated by the PMD entity, forwards received data to the PLCP sublayer. The data 
clock for this primitive shall be supplied by the PMD layer based on the PN code repetition. 

15.4.5.2.4 Effect of receipt 

The PLCP sublayer either interprets the bit or bits that are recovered as part of the PLCP convergence proce- 
dure or passes the data to the MAC sublayer as part of the MPDU. 

15.4.5.3 PMD_TXSTART.request 

15.4.5.3.1 Function 

This primitive, which is generated by the PHY PLCP sublayer, initiates PPDU transmission by the PMD 
layer. 

15.4.5.3.2 Semantics of the service primitive 

The primitive shall provide-the following parameter: 
PMD_TXSTART. request 

15.4.5.3.3 When generated 

This primitive shall be generated by the PLCP sublayer to initiate the PMD layer transmission of the PPDU. 
The PHY- DATA. request primitive shall be provided to the PLCP sublayer prior to issuing the 
PMD.TXSTART command. 
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15.4.5.3.4 Effect of receipt 

PMD_TXSTART initiates transmission of a PPDU by the PMD sublayer. 

15.4.5.4 PMD_TXEND. request 

15.4.5.4.1 Function 

This primitive, which is generated by the PHY PLCP sublayer, ends PPDU transmission by the PMD layer. 

15.4.5.4.2 Semantics of the service primitive 
The semantics of the primitive are as follows: 

PMD_TXEND. request 

15.4.5.4.3 When generated 

This primitive shall be generated by the PLCP sublayer to terminate the PMD layer transmission of the 
PPDU. 

15.4.5.4.4 Effect of receipt 

PMD_TXEND terminates transmission of a PPDU by the PMD sublayer. 

15.4.5.5 PMD_ANTSEL.request 

15.4.5.5.1 Function 

This primitive, which is generated by the PHY PLCP sublayer, selects the antenna used by the PHY for 
transmission or reception (when diversity is disabled). 

15.4.5.5.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD_ANTSEL.request(ANT_STATE) 

ANT_STATE selects which of the available antennas should be used for transmit. The number of available 
antennas shall be determined from the MIB table parameters aSuprtRxAntennas and aSuprtTxAntennas. 

15.4.5.5.3 When generated 

This primitive shall be generated by the PLCP sublayer to select a specific antenna for transmission or 
reception (when diversity is disabled). 

15.4.5.5.4 Effect of receipt 

PMD_ANTSEL immediately selects the antenna specified by ANT_STATE. 

2 10 Copyright © 1999 IEEE. All rights reserved. 



ISO/IEC 8802 11' 1999fEl 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.11, 1999 Edition 

15.4.5.6 PMD.ANTSEL.indicate 

15.4.5.6.1 Function 

This primitive, which is generated by the PHY PLCP sublayer, reports the antenna used by the PHY for 
reception of the most recent packet. 

15.4.5.6.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD_ANTSEL.indicate(ANT_STATE) 
ANT_STATE reports which of the available antennas was used for reception of the most recent packet. 

15.4.5.6.3 When generated 

This primitive shall be generated by the PLCP sublayer to report the antenna used for the most recent packet 
reception. 

15.4.5.6.4 Effect of receipt 

PMD_ANTSEL immediately reports the antenna specified by ANT_STATE. 

15.4.5.7 PMD.TXPWRLVL.request 

15.4.5.7.1 Function 

This primitive, which is generated by the PHY PLCP sublayer, selects the power level used by the PHY for 
transmission. 

15.4.5.7.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD_TXPWRLVL.request(TXPWR_LEVEL) 

TXPWR_LEVEL selects which of the optional transmit power levels should be used for the current packet 
transmission. The number of available power levels shall be determined by the MIB parameter 
dotl INumberSupportedPowerLevels. Subclause 1 5.4.7.3 provides further information on the optional DSSS 
PHY power- level-control capabilities. 

15.4.5.7.3 When generated 

This primitive shall be generated by the PLCP sublayer to select a specific transmit power. This primitive 
shall be applied prior to setting PMD_TXSTART to the transmit state. 

1 5.4.5.7.4 Effect of receipt 

PMDJTXPWRLVL immediately sets the transmit power level given by TXPWR_LEVEL. 
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15.4.5.8 PMD_RATE.request 

15.4.5.8.1 Function 

This primitive, which is generated by the PHY PLCP sublayer, selects the modulation rate that shall be used 
by the DSSS PHY for transmission. 

15.4.5.8.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD_RATE.request(RATE) 

The RATE parameter selects which of the DSSS PHY data rates shall be used for MPDU transmission. Sub- 
clause 1 5.4.6.4 provides further information on the DSSS PHY modulation rates. The DSSS PHY rate 
change capability is fully described in 15.2. 

15.4.5.8.3 When generated 

This primitive shall be generated by the PLCP sublayer to change or set the current DSSS PHY modulation 
rate used for the MPDU portion of a PPDU. 

1 5.4.5.8.4 Effect of receipt 

The receipt of PMDJIATE selects the rate that shall be used for all subsequent MPDU transmissions. This 
rate shall be used for transmission only. The DSSS PHY shall still be capable of receiving all the required 
DSSS PHY modulation rates. 

15.4.5.9 PMD.RATE.indicate 

15.4.5.9.1 Function 

This primitive, which is generated by the PMD sublayer, indicates which modulation rate was used to 
receive the MPDU portion of the PPDU. The modulation shall be indicated in the PLCP Preamble IEEE 
802. II SIGNALING field. 

15.4.5.9.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD_RATE.indicate(RATE) 

In receive mode, the RATE parameter informs the PLCP layer which of the DSSS PHY data rates was used 
to process the MPDU portion of the PPDU. Subclause 15.4.6.4 provides further information on the DSSS 
PHY modulation rates. The DSSS PHY rate change capability is fully described in 15.2. 

15.4.5.9.3 When generated 

This primitive shall be generated by the PMD sublayer when the PLCP Preamble IEEE 802. 1 1 SIGNALING 
field has been properly detected. 

1 5.4.5.9.4 Effect of receipt 

This parameter shall be provided to the PLCP layer for information only. 
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15.4.5.10 PMD.RSSI.indicat 

15.4.5.10.1 Function 

This optional primitive, which is generated by the PMD sublayer, provides to the PLCP and MAC entity the 
received signal strength. 

15.4.5.10.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 

PMD.RSSI.indicate(RSSI) 

The RSSI shall be a measure of the RF energy received by the DSSS PHY. RSSI indications of up to 8 bits 
(256 levels) are supported. 

15.4.5.10.3 When generated 

This primitive shall be generated by the PMD when the DSSS PHY is in the receive state. It shall be contin- 
uously available to the PLCP, which, in turn, provides the parameter to the MAC entity. 

15.4.5.10.4 Effect of receipt 

This parameter shall be provided to the PLCP layer for information only. The RSSI may be used in conjunc- 
tion with signal quality (SQ) as part of a CCA scheme. 

15.4.5.11 PMD_SQ.indicate 

15.4.5.11.1 Function 

This optional primitive, which is generated by the PMD sublayer, provides to the PLCP and MAC entity the 
SQ of the DSSS PHY PN code correlation. The SQ shall be sampled when the DSSS PHY achieves code 
lock and shall be held until the next code lock acquisition. 

15.4.5.11.2 Semantics of the service primitive 

The primitive shall provide the following parameter: 
PMD_SQ.indicate(SQ) 

The SQ shall be a measure of the PN code correlation quality received by the DSSS PHY SQ indications of 
up to 8 bits (256 levels) are supported. 

15.4.5.1 1.3 When generated 

This primitive shall be generated by the PMD when the DSSS PHY is in the receive state and code lock is 
achieved. It shall be continuously available to the PLCP, which, in turn, provides the parameter to the MAC 
entity. 

1 5.4.5.1 1 .4 Effect of receipt 

This parameter shall be provided to the PLCP layer for information only. The SQ may be used in conjunc- 
tion with RSSI as part of a CCA scheme. 
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15.4.5.12 PMD_CS.indicate 

15.4.5.12.1 Function 

This primitive, which is generated by the PMD, shall indicate to the PLCP layer that the receiver has 
acquired (locked) the PN code and data is being demodulated. 

15.4.5.12.2 Semantics of the service primitive 

The PMD_CS (carrier sense) primitive in conjunction with PMD_ED provides CCA status through the 
PLCP layer PHYCCA primitive. PMD_CS indicates a binary status of ENABLED or DISABLED. 
PMD_CS shall be ENABLED when the correlator SQ indicated in PMD_SQ is greater than the 
CS_THRESHOLD parameter. PMD_CS shall be DISABLED when the PMD_SQ falls below the correla- 
tion threshold. 

15.4.5.12.3 When generated 

This primitive shall be generated by the PHY sublayer when the DSSS PHY is receiving a PPDU and the PN 
code has been acquired. 

15.4.5.12.4 Effect of receipt 

This indicator shall be provided to the PLCP for forwarding to the MAC entity for information purposes 
through the PHYCCA indicator. This parameter shall indicate that the RF medium is busy and occupied by a 
DSSS PHY signal. The DSSS PHY should not be placed into the transmit state when PMD_CS is 
ENABLED. 

15.4.5.13 PMD_ED.tndicate 

15.4.5.13.1 Function 

This optional primitive, which is generated by the PMD, shall indicate to the PLCP layer that the receiver 
has detected RF energy indicated by the PMD_RSSI primitive that is above a predefined threshold. 

15.4.5.13.2 Semantics of the service primitive 

The PMD_ED (energy detect) primitive, along with the PMD_SQ, provides CCA status at the PLCP layer 
through the PHYCCA primitive. PMD_ED indicates a binary status of ENABLED or DISABLED. 
PMD_ED shall be ENABLED when the RSSI indicated in PMD_RSSI is greater than the 
ED_THRESHOLD parameter. PMD_ED shall be DISABLED when the PMD_RSSI falls below the energy 
detect threshold. 

15.4.5.13.3 When generated 

This primitive shall be generated by the PHY sublayer when the PHY is receiving RF energy from any 
source that exceeds the ED_THRESHOLD parameter. 

15.4.5.13.4 Effect of receipt 

This indicator shall be provided to the PLCP for forwarding to the MAC entity for information purposes 
through the PMD_ED indicator. This parameter shall indicate that the RF medium may be busy with an RF 
energy source that is not DSSS PHY compliant. If a DSSS PHY source is being received, the PMD_CS 
function shall be enabled shortly after the PMD_ED function is enabled. 



214 



Copyright © 1999 IEEE. AN rights reserved. 



ISO/IEC 8802-11: 1999(E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.1 1 , 1999 Edition 

15.4.5.14 PMD.ED.request 

15.4.5.14.1 Function 

This optional primitive, which is generated by the PHY PLCP, sets the energy detect ED_THRESHOLD 
value. 

15.4.5.14.2 Semantics of the service primitive 

The primitive shall provide the following parameters: 

PMD_ED.request(ED_THRESHOLD) 
ED_THRESHOLD is the value that the RSSI indicated shall exceed for PMD_ED to be enabled. 

15.4.5.14.3 When generated 

This primitive shall be generated by the PLCP sublayer to change or set the current DSSS PHY energy 
detect threshold. 

15.4.5.14.4 Effect of receipt 

The receipt of PMD_ED immediately changes the energy detection threshold as set by the 
ED_THRESHOLD parameter. 

15.4.5.15 PHY-CCA.indicate 

15.4.5.15.1 Function 

This primitive, which is generated by the PMD, indicates to the PLCP layer that the receiver has detected RF 
energy that adheres to the CCA algorithm. 

15.4.5.15.2 Semantics of the service primitive 

The PHY-CCA primitive provides CCA status at the PLCP layer to the MAC. 

15.4.5.15.3 When generated 

This primitive shall be generated by the PHY sublayer when the PHY is receiving RF energy from any 
source that exceeds the ED_THRESHOLD parameter (PMD_ED is active), and optionally is a valid corre- 
lated DSSS PHY signal whereby PMD_CS would also be active. 

15.4.5.15.4 Effect of receipt 

This indicator shall be provided to the PLCP for forwarding to the MAC entity for information purposes 
through the PHY-CCA indicator. This parameter indicates that the RF medium may be busy with an RF 
energy source that may or may not be DSSS PHY compliant. If a DSSS PHY source is being received, the 
PMD_CS function shall be enabled shortly after the PMD_ED function is enabled. 

15.4.6 PMD operating specifications, general 

The following subclauses provide general specifications for the DSSS PMD sublayer. These specifications 
apply to both the Receive and the Transmit functions and general operation of a DSSS PHY. 



Copyright © 1999 IEEE, All rights reserved. 



215 



ISO/IEC 8802-11: 1999(E) 
ANSI/IEEE Std 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



15.4.6.1 Operating frequency rang 

The DSSS PHY shall operate in the frequency range of 2,4 GHz to 2.4835 GHz as allocated by regulatory 
bodies in the USA and Europe or in the 2.47 1 GHz to 2.497 GHz frequency band as allocated by regulatory 
authority in Japan. 

1 5.4.6.2 Number of operating channels 

The channel center frequencies and CHNLJD numbers shall be as shown in Table 64. The FCC (US), IC 
(Canada), and ETSI (Europe) specify operation from 2.4 GHz to 2.4835 GHz. For MKK (Japan), operation is 
specified as 2.471 GHz to 2.497 GHz. France allows operation from 2.4465 GHz to 2.4835 GHz, and Spain 
allows operation from 2.445 GHz to 2.475 GHz. For each supported regulatory domain, all channels in Table 
64 marked with "X" shall be supported. 



Table 64— DSSS PHY frequency channel plan 







Regulatory domains 


CHNL.ID 


Frequency 


X'10' 
FCC 


X'20' 
IC 


X'30' 
ETSI 


X3r 

Spain 


X f 32' 
France 


X^O* 
MKK 


1 


2412 MHz 


X 


X 


X 








2 


2417 MHz 


X 


X 


X 








3 


2422 MHz 


X 


X 


X 








4 


2427 MHz 


X 


X 


X 








5 


2432 MHz 


X 


X 


X 








6 


2437 MHz 


X 


X 


X 








7 


2442 MHz 


X 


X 


X 








8 


2447 MHz 


X 


X 


X 








9 


2452 MHz 


X 


X 


X 








to 


2457 MHz 


X 


X 


X 


X 


X 




11 


2462 MHz 


X 


X 


X 


X 


X 




12 


2467 MHz 






X 




X 




13 


2472 MHz 






X 




X 




14 


2484 MHz 












X 



In a multiple cell, network topology, overlapping and/or adjacent cells using different channels can operate 
simultaneously without interference if the distance between the center frequencies is at least 30 MHz. Chan- 
nel 14 shall be designated specifically for operation in Japan. 

15.4.6.3 Spreading sequence 

The following 1 1-chip Barker sequence shall be used as the PN code sequence: 
+1,-1, +!,+!,-!, +1, +1, +1,-1, -1,-1 
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The leftmost chip shall be output first in time. The first chip shall be aligned at the start of a transmitted 
symbol. The symbol duration shall be exactly 1 1 chips long. 

15.4.6.4 Modulation and channel data rates 

Two modulation formats and data rates are specified for the DSSS PHY: a basic access rate and an enhanced 
access rate. The basic access rate shall be based on I Mbit/s DBPSK modulation. The DBPSK encoder is 
specified in Table 65. The enhanced access rate shall be based on 2 Mbit/s DQPSIC. The DQPSK encoder is 
specified in Table 66. (In the tables, +jo> shall be defined as counterclockwise rotation.) 



Table 65—1 Mbit/s DBPSK encoding table 



Bit input 


Phase change (+jo>) 


0 


0 


1 


71 


Table 66—2 Mbit/s DQPSK encoding table 


Dibit pattern (dO,dl) 
dO is first in time 


Phase change (+ja>) 


00 


0 


01 


71/2 


11 


7t 


10 


3k/2 (-71/2) 



15.4.6.5 Transmit and receive in-band and out-of-band spurious emissions 

The DSSS PHY shall conform with in-band and out-of-band spurious emissions as set by regulatory bodies. 
For the USA, refer to FCC 15.247, 15.205, and 15.209. For Europe, refer to ETS 300-328. " 

1 5.4.6.6 Transmit-to-receive turnaround time 

The TX-to-RX turnaround time shall be less than 10 us, including the power-down ramp specified in 
15.4.7.7. 

The TX-to-RX turnaround time shall be measured at the air interface from the trailing edge of the last trans- 
mitted symbol to valid CCA detection of the incoming signal. The CCA should occur within 25 us ( 10 us for 
turnaround time plus 15 us for energy detect) or by the next slot boundary occurring after 25 us has elapsed 
(refer to 15.4.8.4). A receiver input signal 3 dB above the ED threshold described in 15.4.8.4 shall be present 
at the receiver. 

15.4.6.7 Receive-to-transmit turnaround time 

The RX-to-TX turnaround time shall be measured at the MAC/PHY interface, using PH YTXSTART.request 
and shall be <5 us. This includes the transmit power-up ramp described in 1 5,4.7.7. 
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15.4.6.8 Slot time 

The slot time for the DSSS PHY shall be the sum of the RX-to-TX turnaround time (5 us) and the energy 
detect time (15 us specified in 15.4.8.4). The propagation delay shall be regarded as being included in the 
energy detect time. 

15.4.6.9 Transmit and receive antenna port impedance 

The impedance of the transmit and receive antenna port(s) shall be 50 Q if the port is exposed. 

15.4.6.10 Transmit and receive operating temperature range 

Three temperature ranges for full operation compliance to the DSSS PHY are specified in Clause 13. Type 1 
shall be defined as 0 °C to 40 °C, and is designated for office environments. Type 2 shall be defined as -20 °C 
to +50 °C, and Type 3 shall be defined as -30 °C to +70 °C. Types 2 and 3 are designated for industrial environ- 
ments. 

15.4.7 PMD transmit specifications 

The following subclauses describe the transmit functions and parameters associated with the PMD sublayer. 
15.4.7.1 Transmit power levels 

The maximum allowable output power as measured in accordance with practices specified by the regulatory 
bodies is shown in Table 67. In the USA, the radiated emissions should also conform with the IEEE uncon- 
trolled radiation emission standard (IEEE Std C95.1-1991). 



Table 67 — Transmit power levels 



Maximum output power 


Geographic location 


Compliance document 


lOOOmW 


USA 


FCC 15.247 


100 mW(EIRP) 


Europe 


ETS 300-328 


lOmW/MHz 


Japan 


MPT ordinance for Regulating Radio 
Equipment, Article 49-20 



15.4.7.2 Minimum transmitted power level 

The minimum transmitted power shall be no less than 1 mW. 

15.4.7.3 Transmit power level control 

Power control shall be provided for transmitted power greater than 100 mW. A maximum of four power 
levels may be provided. At a minimum, a radio capable of transmission greater than 100 mW shall be capa- 
ble of switching power back to 100 mW or less. 

15.4.7.4 Transmit spectrum mask 

The transmitted spectral products shall be less than -30 dBr (dB relative to the SINx/x peak) for f c - 22 MHz 
< f<f c -1 1 MHz,/ c +1 1 MHz <f<f c + 22 MHz, -50 dBr for f<f c -22 MHz, and/> f c + 22 MHz, where/ c 
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is the channel center frequency. The transmit spectral mask is shown in Figure 96. The measurements shall 
be made using 100 kHz resolution bandwidth and a 30 kHz video bandwidth. 




j . | j 

fc-22MHz fc-11MHz fc fc+11MHz fc +22 Mhz 

Figure 96— Transmit spectrum mask 



15.4.7.5 Transmit center frequency tolerance 

The transmitted center frequency tolerance shall be ±25 ppm maximum. 

15.4.7.6 Chip clock frequency tolerance 

The PN code chip clock frequency tolerance shall be better than ±25 ppm maximum. 

15.4.7.7 Transmit power-on and power-down ramp 

The transmit power-on ramp for 10% to 90% of maximum power shall be no greater than 2 us. The transmit 
power-on ramp is shown in Figure 97. 



Transmit 

Power 

Output 




Figure 97— Transmit power-on ramp 



The transmit power-down ramp for 90% to 10% maximum power shall be no greater than 2 us. The transmit 
power down ramp is shown in Figure 98. 

The transmit power ramps shall be constructed such that the DSSS PHY emissions conform with the spuri- 
ous frequency product specification defined in 15.4.6.5. 
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Transmit 

Power 

Output 



Max TX Power 
90% MAX 




Time \xs 



Figure 98 — Transmit power-down ramp 



15.4.7.8 RF carrier suppression 



The RF carrier suppression, measured at the channel center frequency, shall be at least 1 5 dB below the peak 
SIN(x)/x power spectrum. The RF carrier suppression shall be measured while transmitting a repetitive 01 
data sequence with the scrambler disabled using DQPSK. modulation. A 100 kHz resolution bandwidth shall 
be used to perform this measurement. 



15.4.7.9 Transmit modulation accuracy 



The transmit modulation accuracy requirement for the DSSS PHY shall be based on the difference between the 
actual transmitted waveform and the ideal signal waveform. Modulation accuracy shall be determined by 
measuring the peak vector error magnitude measured during each chip period. Worst-case vector error magni- 
tude shall not exceed 0.35 for the normalized sampled chip data. The ideal complex 1 and Q constellation points 
associated with DQPSK modulation (0.707,0.707), (0.707, -0.707), (-0.707, 0.707), (-0.707, -0.707) shall be 
used as the reference. These measurements shall be from baseband I and Q sampled data after recovery through 
a reference receiver system. 

Figure 99 illustrates the ideal DQPSK constellation points and range of worst-case error specified for modu- 
lation accuracy. 



Error vector measurement requires a reference receiver capable of carrier lock. All measurements shall be 
made under carrier lock conditions. The distortion induced in the constellation by the reference receiver 
shall be calibrated and measured. The test data error vectors described below shall be corrected to compen- 
sate for the reference receiver distortion. 



The IEEE 802.1 1 vendor compatible radio shall provide an exposed TX chip clock, which shall be used to 
sample the I and Q outputs r>f the reference receiver. 

The measurement shall be made under the conditions of continuous DQPSK transmission usine scrambled 
all Is. 



The eye pattern of the I channel shall be used to determine the / and Q sampling point. The chip clock 
provided by the vendor radio shall be time delayed such that the samples fall at a 1/2 chip period offset from 
the mean of the zero crossing positions of the eye (see Figure 100). This is the ideal center of the eye and 
may not be the point of maximum eye opening. 
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Ideal Constellation Point 



Measured Point 



" "Error Vector 



Figure 99— Modulation accuracy measurement example 




Geometric 
Center 



* Time 



Vendor 
Chip Clock 



Figure 100— Chip clock alignment with baseband eye pattern 

Using the aligned chip clock, I000 samples of the / and Q baseband outputs from the reference receiver are 
captured. The vector error magnitudes shall be calculated as follows: 

Calculate the dc offsets for / and Q samples. 



i ooo 



1000 

iieooi/iooo 
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Calculate the dc corrected / and Q samples for all n =1000 sample pairs. 

/dc(")= Hn) - /mean 
Qdc(")= e(«)-0mean 
Calculate the average magnitude of /and Q samples. 

1000 

' mi , s = I |/ dc («)|/iooo 

n = 1 
1000 

2n, 0g = X |e*:{«)|/IOOO 

n = 1 

Calculate the normalized error vector magnitude for the Idc( n VQdc( n ) pairs. 



KJ") = [| X ({ |/ dc (/>)|// nlil ,} 2 + { iQ^npQn^ 2 )] 2 ~ ^wecuon 

w i tn ^correction ~ error induced by the reference receiver system. 

A vendor DSSS PHY implementation shall be compliant if for all n =1000 samples the following condition 
is met: 

K e »<0.35 

15.4.8 PMD receiver specifications 

The following subclauses describe the receive functions and parameters associated with the PMD sublayer. 

15.4.8.1 Receiver minimum input level sensitivity 

The frame error ratio (FER) shall be less than 8x 10" 2 at an MPDU length of 1024 bytes for an input level of 
-80 dBm measured at the antenna connector. This FER shall be specified for 2 Mbit/s DQPSK modulation. 
The test for the minimum input level sensitivity shall be conducted with the energy detection threshold set 
< -80 dBm. 

15.4.8.2 Receiver maximum input level 

The receiver shall provide a maximum FER of 8x 10~ 2 at an MPDU length of 1024 bytes for a maximum input 
level of -4 dBm measured althe antenna. This FER shall be specified for 2 Mbit/s DQPSK modulation. 

15.4.8.3 Receiver adjacent channel rejection 

Adjacent channel rejection is defined between any two channels with >30 MHz separation in each channel 
group defined in 15.4.6.2. 

The adjacent channel rejection shall be > 35 dB with an FER of 8x 10" 2 using 2 Mbit/s DQPSK modulation 
described in 15.4.6.4 and an MPDU length of 1024 bytes. 
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The adjacent channel rejection shall be measured using the following method: 

Input a 2 Mbit/s DQPSK modulated signal at a level 6 dB greater than specified in 1 5.4.8.1. In an adjacent 
channel (>30 MHz separation as defined by the channel numbering), input a signal modulated in a similar 
fashion that adheres to the transmit mask specified in 15.4.7.4 to a level 41 dB above the level specified in 
1 5,4.8. 1 The adjacent channel signal shall be derived from a separate signal source. It cannot be a frequency 
shifted version of the reference channel. Under these conditions, the FER shall be no worse than 8x I0" 2 . 

15.4.8.4 CCA 

The DSSS PHY shall provide the capability to perform CCA according to at least one of the following three 
methods: 

— CCA Mode 1: Energy above threshold. CCA shall report a busy medium upon detection of any 
energy above the ED threshold. 

— CCA Mode 2: Carrier sense only. CCA shall report a busy medium only upon detection of a DSSS 
signal. This signal may be above or below the ED threshold. 

— CCA Mode 3: Carrier sense with energy above threshold. CCA shall report a busy medium upon 
detection of a DSSS signal with energy above the ED threshold. 

The energy detection status shall be given by the PMD primitive, PMD_ED. The carrier sense status shall be 
given by PMD_CS. The status of PMD_ED and PMD_CS is used in the PLCP convergence procedure to 
indicate activity to the MAC through the PHY interface primitive PHY-CCA.indicate. 

A busy channel shall be indicated by PHY-CCA.indicate of class BUSY. 

A clear channel shall be indicated by PHY-CCA.indicate of class IDLE. 

The PHY MIB attribute dotl lCCAModeSupported shall indicate the appropriate operation modes. The 
PHY shall be configured through the PHY MIB attribute dotl ICurrentCCAMode. 

The CCA shall be TRUE if there is no energy detect or carrier sense. The CCA parameters are subject to the 
following criteria: 

a) The energy detection threshold shall be < -80 dBm for TX power > 100 mW, -76 dBm for 50 mW < 
TX power < 100 mW, and -70 dBm for TX power < 50 mW. 

b) With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 
5 us of the start of a MAC slot boundary, the CCA indicator shall report channel busy before the end 
of the slot time. This implies that the CCA signal is available as an exposed test point. Refer to Fig- 
ure 47 for a definition of slot time boundary. 

c) In the event that a correct PLCP Header is received, the DSSS PHY shall hold the CCA signal inac- 
tive (channel busy) for the full duration as indicated by the PLCP LENGTH field. Should a loss of 
carrier sense occur in the middle of reception, the CCA shall indicate a busy medium for the 
intended duration of the transmitted packet. 

Conformance to DSSS PHY CCA shall be demonstrated by applying a DSSS compliant signal, above the 
appropriate ED threshold a), such that all conditions described in b) and c) above are demonstrated. 
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16. Infrared (IR) PHY specification 
16.1 Overview 

The physical layer for the infrared system is specified in this clause. The IR PHY uses near-visible light in 
the 850 nm to 950 nm range for signaling. This is similar to the spectral usage of both common consumer 
devices such as infrared remote controls, as well as other data communications equipment, such as Infrared 
Data Association (IrDA) devices. 

Unlike many other infrared devices, however, the I R PHY is not directed. That is, the receiver and transmit- 
ter do not have to be aimed at each other and do not need a clear line-of-sight. This permits the construction 
of a true LAN system, whereas with an aimed system, it would be difficult or impossible to install a LAN 
because of physical constraints. 

A pair of conformant infrared devices would be able to communicate in a typical environment at a range up 
to about 10 m. This standard allows conformant devices to have more sensitive receivers, and this may 
increase range up to about 20 m. 

The IR PHY relies on both reflected infrared energy as well as line-of-sight infrared energy for communica- 
tions. Most designs anticipate that all of the energy at the receiver is reflected energy. This reliance on 
reflected infrared energy is called diffuse infrared transmission. 

This standard specifies the transmitter and receiver in such a way that a conformant design will operate well 
in most environments where there is no line-of-sight path from the transmitter to the receiver. However, in an 
environment that has few or no reflecting surfaces, and where there is no line-of-sight, an IR PHY system 
may suffer reduced range. 

The IR PHY will operate only in indoor environments. Infrared radiation does not pass through walls, and is 
significantly attenuated passing through most exterior windows. This characteristic can be used to "contain" 
an IR PHY in a single physical room, like a classroom or conference room. Different LANs using the IR 
PHY can operate in adjacent rooms separated only by a wall without interference, and without the possibil- 
ity of eavesdropping. 

At the time of this standard's preparation, the only known regulatory standards that apply to the use of infra- 
red radiation are safety regulations, such as IEC 60825-1: 1998 [B2] and ANSI Z136. 1-1993 [Bl]. While a 
conformant IR PHY device can be designed to also comply with these safety standards, conformance with 
this standard does not ensure conformance with other standards. 

Worldwide, there are currently no frequency allocation or bandwidth allocation regulatory restrictions on 
infrared emissions. 

Emitter (typically LED) and detector (typically PIN diode) devices for infrared communications are rela- 
tively inexpensive at the infrared wavelengths specified in the IR PHY, and at the electrical operating fre- 
quencies required by this PHY. 

While many other devices in common use also use infrared emissions in the same optical band, these devices 
usually transmit infrared intermittently and do not interfere with the proper operation of a compliant IR 
PHY If such a device does interfere, by transmitting continuously and with a very strong signal, it can be 
physically isolated (placing it in a different room) from the IEEE 802. 1 1 LAN. 
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16.1.1 Scop 

The PHY services provided to the IEEE 802. 1 1 wireless LAN MAC by the IR system are described in this 
clause. The IR PHY layer consists of two protocol functions as follows: 

a) A physical layer convergence function, which adapts the capabilities of the physical medium depen- 
dent (PMD) system to the PHY service. This function is supported by the physical layer conver- 
gence procedure (PLCP), which defines a method of mapping the IEEE 802. 1 1 MAC sublayer 
protocol data units (MPDU) into a framing format suitable for sending and receiving user data and 
management information between two or more STAs using the associated PMD system. 

b) A PMD system, whose function defines the characteristics of, and method of transmitting and receiv- 
ing data through, the wireless medium ( WM) between two or more STAs. 

16.1.2 IR PHY functions 

The IR PHY contains three functional entities: the PMD function, the physical layer convergence function, 
and the layer management function. Each of these functions is described in detail below. 

The IR PHY service is provided to the MAC entity at the STA through a service access point (SAP) as 
described in Clause 12. For a visual guide to the relationship of the IR PHY to the remainder of the system, 
refer to Figure 1 1 . 

16.1.2.1 PLCP sublayer 

To allow the IEEE 802. 1 1 MAC to operate with minimum dependence on the PMD sublayer, a physical 
layer convergence sublayer is defined. This function simplifies the PHY service interface to the IEEE 802. 1 1 
MAC services. The PHY-specific preamble is normally associated with this convergence layer. 

16.1.2.2 PMD sublayer 

The PMD sublayer provides a clear channel assessment (CCA) mechanism, transmission mechanism, and 
reception mechanism that are used by the MAC via the PLCP to send or receive data between two or more 
STAs. 

16.1.2.3 PHY management entity (PLME) 

The PLME performs management of the local PHY functions in conjunction with the MAC management 
entity. Subclause 16.4 lists the MIB variables that may be accessed by the PHY sublayer entities and intra- 
layer of higher-layer management entities (LMEs). These variables are accessed via the PLME-GET, 
PLME-SET, and PLME-RESET primitives defined in Clause 10. 

16.1.3 Service specification method and notation 

The models represented by figures and state diagrams are intended as illustrations of functions provided. It is 
important to distinguish between a model and a real implementation. The models are optimized for simplic- 
ity and clarity of presentation; the actual method of implementation is left to the discretion of the IEEE 
802. 1 1 IR PHY compliant developer. Conformance to this standard is not dependent on following the model, 
and an implementation that follows the model closely may not be conformant. 

Abstract services are specified here by describing the service primitives and parameters that characterize 
each service. This definition is independent of any particular implementation. In particular, the PHY-SAP 
operations are defined and described as instantaneous; however, this may be difficult to achieve in an imple- 
mentation. 
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16.2 IRPLCP sublayer 

While the PLCP sublayer and the PMD sublayer are described separately, the separation and distinction 
between these sublayers is artificial, and is not meant to imply that the implementation must separate these 
functions. This distinction is made primarily to provide a point of reference from which to describe certain 
functional components and aspects of the PMD. The functions of the PLCP can be subsumed by a PMD sub- 
layer; in this case, the PMD will incorporate the PHY-SAP as its interface, and will not offer a PMD-SAP. 

16.2.1 Overview 

A convergence procedure is provided by which MPDUs are converted to and from PLCPDUs. During trans- 
mission, the MPDU (PLCSDU) is prepended with a PLCP Preamble and PLCP Header to create the 
PLCPDU. At the receiver, the PLCP Preamble is processed and the internal data fields are processed to aid in 
demodulation and delivery of the MPDU (PSDU). 

16.2.2 PLCP frame format 

Figure 101 shows the format for the PLCPDU including the PLCP Preamble, the PLCP Header, and the PSDU. 
The PLCP Preamble contains the following fields: Synchronization (SYNC) and Start Frame Delimiter (SFD). 
The PLCP Header contains the following fields: Data Rate (DR), DC Level Adjustment (DCLA), Length 
(LENGTH), and Cyclic Redundancy Check (CRC). Each of these fields is described in detail in 1 6.2.4. 



PLCP Preamble 


PLCP Header 


SYNC 


SFD 


DR 


DCLA 


LENGTH 


CRC 



PSDU 



57- 73 slots 4 slots 3 slots 32 slots 16 bits 16 bits variable number of octets 
Figure 101— PLCPDU frame format 

16.2.3 PLCP modulation and rate change 

The PLCP Preamble shall be transmitted using the basic pulse defined in 1 6.3.3. 2. The PLCSDU, LENGTH, 
and CRC fields shall be transmitted using pulse position modulation (PPM). PPM maps bits in the octet into 
symbols: 16-PPM maps four bits into a 16-position symbol, and 4-PPM maps two bits into a 4-position 
symbol. The basic L-PPM time unit is the slot. A slot corresponds to one of the L positions of a symbol and 
has a 250 ns duration. The PLCSDU, LENGTH, and CRC fields are transmitted at one of two bit rates: 
1 Mbit/s or 2 Mbit/s. The Data Rate field indicates the data rate that will be used to transmit the PLCSDU, 
LENGTH, and CRC fields. The 1 Mbit/s data rate uses 16-PPM (basic access rate), and the 2 Mbit/s data 
rate uses 4-PPM (enhanced access rate). The transmitter and receiver will initiate the modulation or demod- 
ulation indicated*by the DR field starting with the first 4 bits (in 16-PPM) or 2 bits (in 4-PPM) of the 
LENGTH field. The PSDU transmission rate is set by the DATARATE parameter in the PHY- 
TXSTART.request primitive. Any conformant IR PHY shall be capable of receiving at 1 Mbit/s and 2 Mbit/ 
s. Transmission at 2 Mbit/s is optional. 

A PHY-TXSTART.request that specifies a data rate that is not supported by a PHY instance will cause the 
PHY to indicate an error to its MAC instance. A PHY is not permitted under any circumstance to transmit at 
a different rate than the requested rate. 
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16.2.4 PLCP field definitions 

16.2.4.1 PLCP Synchronization (SYNC) fi Id 

The SYNC field consists of a sequence of alternated presence and absence of a pulse in consecutive slots. 
The SYNC field has a minimum length of 57 L-PPM slots and a maximum length of 73 L-PPM slots and 
shall terminate with the absence of a pulse in the last slot. This field is provided so that the receiver can per- 
form clock recovery (slot synchronization), automatic gain control (optional), signal-to-noise ratio estima- 
tion (optional), and diversity selection (optional). 

The SYNC field is not modulated using L-PPM, but instead consists of transitions in L-PPM slots that would 
otherwise constitute an illegal symbol. See 16.3.2.1 for legal symbols. 

16.2.4.2 PLCP Start Frame Delimiter (SFD) field 

The SFD field length is four L-PPM slots and consists of the binary sequence 100 1, where I indicates a 
pulse in the L-PPM slot and 0 indicates no pulse in the L-PPM slot. The leftmost bit shall be transmitted 
first. The SFD field is provided to indicate the start of the PLCP Preamble and to perform bit and symbol 
synchronization. 

The SFD field is not modulated using L-PPM, but instead consists of transitions in L-PPM slots that would 
otherwise constitute an illegal symbol. 

16.2.4.3 PLCP Data Rate (DR) field 

The DR field indicates to the PHY the data rate that shall be used for the transmission or reception of the 
PLCSDU, LENGTH, and CRC fields. The transmitted value shall be provided by the PHY-* 
TXSTART.request primitive as described in Clause 12. The DR field has a length of three L-PPM slots. 
The leftmost bit, as shown below, shall be transmitted first. The IR PHY currently supports two data rates 
defined by the slot pattern shown for the three L-PPM slots following the SFD, where 1 indicates a pulse in 
the L-PPM slot and 0 indicates no pulse in the L-PPM slot: 

1 Mbit/s: 000 
2Mbit/s: 001 

The DR field is not modulated using L-PPM, but instead consists of transitions in L-PPM slots that would 
otherwise constitute an illegal symbol. 

16.2.4.4 PLCP DC Level Adjustment (DCLA) field 

The DCLA field is required to allow the receiver to stabilize the dc level after the SYNC, SFD, and DR 
fields. The leftmost bit, as shown below, shall be transmitted first. The length of the DCLA field is 32 L-PPM 
slots and consists of the contents shown, where I indicates a pulse in the L-PPM slot and 0 indicates no 
pulse in the L-PPM slot: 

1 Mbit/s: 00000000 1 000000000000000 10000000 

2 Mbit/s: 00100010001000100010001000100010 

The DCLA field is not modulated using L-PPM, but instead consists of transitions in L-PPM slots that 
would otherwise constitute an illegal symbol. 
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16.2.4.5 PLCP LENGTH field 

The LENGTH field is an unsigned 16-bit integer that indicates the number of octets to be transmitted in the 
PSDU. The transmitted value shall be provided by the PHYTXSTARTrequest primitive as described in 
Clause 12. The lsb shall be transmitted first. This field is modulated and sent in L-PPM format. This field is 
protected by the CRC described in 16.2.4.6. 

16.2.4.6 PLCP CRC field 

The LENGTH field shall be protected by a 16-bit CRC-CCITT. The CRC-CCITT is the one's complement 
of the remainder generated by the modulo 2 division of the LENGTH field by the polynomial: 

^ 16 +jc 12 +jc 5 +1 

The protected bits will be processed in transmit order. The msb of the 1 6-bit CRC-CCITT shall be transmitted 
first. This field shall be modulated and sent in L-PPM format. All CRC-CCITT calculations shall be made prior 
to L-PPM encoding on transmission and after L-PPM decoding on reception. 

16.2.4.7 PSDU field 

This field is composed of a variable number of octets. The minimum is 0 (zero) and the maximum is 
2500. The lsb of each octet shall be transmitted first. All the octets of this field shall be modulated and sent in 
L-PPM format. 

16.2.5 PLCP procedures 

16.2.5.1 PLCP transmit procedure 

All commands issued by the MAC require that a confirmation primitive be issued by the PHY. The confirma- 
tion primitives provide flow control between the MAC and the PHY. 

The transmit procedure is as follows: 

a) Based on the status of CCA, the MAC shall determine whether the channel is clear. 

b) If the channel is clear, transmission of the PSDU shall be initiated by a PHY-TXSTART.request with 
parameters LENGTH and DATARATE. 

c) The PHY entity shall immediately initiate transmission of the PLCP Preamble and PLCP Header 
based on the LENGTH and DATARATE parameters passed in the PHY-TXSTART.request. Once the 
PLCP Preamble and PLCP Header transmission is completed, the PHY entity shall issue a PHY- 
TXSTART.confirm. 

d) Each octet of the PSDU is passed from the MAC to the PHY by a single PHY-DATA.request primi- 
' tive. Each PHY-DATA.request shall be confirmed by the PHY with a PHY- DATA. confirm before the 

next request can be made. 

e) At the PHY layer each PSDU octet shall be divided into symbols of 2 bits or 4 bits each. The 
symbols shall be modulated using L-PPM and transmitted into the medium. 

f) Transmission is terminated by the MAC through the primitive PHY-TXEND.request. The PHY shall 
confirm the resulting end of transmission with a PHY-TXEND.confirm. 
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16.2.5.2 PLCP receive procedure 

The receive procedure is as follows: 

a) CCA is provided to the MAC via the PH Y-CCA,indicate primitive. When the PHY senses activity on 
the medium, it shall indicate that the medium is busy with a PHY-CCA.indicate with a value of 
BUSY. This will normally occur during the SYNC field of the PLCP Preamble. 

b) The PHY entity shall begin searching for the SFD field. Once the SFD field is detected, the PHY 
entity shall attempt to receive the PLCP Header. After receiving the DR and DC LA fields, the PHY 
shall initiate processing of the received CRC and LENGTH fields. The data rate indicated in the DR 
field applies to all symbols in the latter part of the received PHYSDU, commencing with the first 
symbol of the LENGTH field. The CRC-CCITT shall be checked for correctness immediately after 
its reception. 

c) If the CRC-CCITT check fails, or the value received in the DR field is not one supported by the 
PHY, then a PHY-RXSTART.indicate shall not be issued to the MAC. When the medium is again 
free, the PHY shall issue a PHY-CCA.indicate with a value of IDLE. 

d) If the PLCP Preamble and PLCP Header reception is successful, the PHY shall send a PHY- 
RXSTART.indicate to the MAC; this includes the parameters DATARATE and LENGTH. 

In the absence of errors, the receiving PHY shall report the same length to its local MAC, in the 
RXVECTOR parameter of the PHY-RXSTART.indicate primitive, that the peer MAC presented to 
its local PHY entity in the TXVECTOR parameter of its respective PHY-TXSTART.request. 

e) The received PLCSDU L-PPM symbols shall be assembled into octets and presented to the MAC 
using a series of PHY-DATA.indicate primitives, one per octet. 

0 Reception shall be terminated after the reception of the final symbol of the last PLCSDU octet indi- 
cated by the PLCP Header's LENGTH field. After the PHY-DATA.indicate for that octet is issued, 
the PHY shall issue a PHY-RXEND.indicate primitive to its MAC. 

g) After issuing the PHY-RXEND.indicate primitive, and when the medium is no longer busy, the PHY 
shall issue a PHY-CCA.indicate primitive with a value of IDLE. 

16.2.5.3 CCA procedure 

CCA is provided to the MAC via the PHY-CCA.indicate primitive. 
The CCA procedure is as follows: 

a) When the PHY senses activity on the medium, a PHY-CCA.indicate primitive with a value of BUSY 
shall be issued. This will normally occur during reception of the SYNC field of the PLCP Preamble. 

b) When the PHY senses that the medium is free, a PHY-CCA.indicate primitive with a value of IDLE 
shall be issued. 

c) At any time, the MAC may issue a PHY-CCARESET.request primitive, which will reset the PHY's 
internal CCA detection mechanism to the medium not-busy (IDLE) state. This primitive will be 
acknowledged with a PHY-CCARESET.confirm primitive. 
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16.2.5.4 PMD__SAP peer-to-peer service primitive parameters 

Several service primitives include a parameter vector. This vector shall be a list of parameters that may vary 
depending on PHY type. Table 68 indicates the parameters required by the MAC or IR PHY in each of the 
parameter vectors used for peer-to-peer interactions. 



Table 68— IR PMD_SAP peer-to-peer service primitives 



Parameter 


Associated primitive 


Value 


LENGTH 


RXVECTOR, TXVECTOR 


4 to 2 16 - 1 


DATARATE 


RXVECTOR, TXVECTOR 


PHY dependent 



16.3 IR PMD sublayer 

The IR PMD sublayer does not define PMD SAPs. The mechanism for communications between the PLCP 
and PMD sublayers, as well as the distinction between these two sublayers, if any, is left to implementors. In 
particular, it is possible to design and implement, in a conformant way, a single sublayer that subsumes the 
functions of both the PLCP and PMD, presenting only the PHY- SAP. 

16.3.1 Overview 

The PMD functional, electrical, and optical characteristics required for interoperability of implementations 
conforming to this specification are described in this subclause. The relationship of this specification to the 
entire IR physical layer is shown in Figure 1 1 . 

16.3.2 PMD operating specifications, general 

General specifications for the IR PMD sublayer are provided in this subclause. These specifications apply to 
both the receive and transmit functions and general operation of a compliant IR PHY. 

16.3.2.1 Modulation and channel data rates 

Two modulation formats and data rates are specified for the IR PHY: a basic access rate and an enhanced 
access rate. The basic access rate is based on 1 Mbit/s 16-PPM modulation. The 16-PPM encoding is speci- 
fied in Table 69. Each group of 4 data bits is mapped to one of the 16-PPM symbols. The enhanced access 
rate is based on 2 Mbit/s 4-PPM. The 4-PPM encoding is specified in Table 70. Each group of 2 data bits is 
mapped to one of the 4-PPM symbols. Transmission order of the symbol slots is from left to right, as shown 
in the table, where a 1 indicates in-band energy in the slot, and a 0 indicates the absence of in-band energy in 
the slot. 
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The data in Table 69 and Table 70 have been arranged (gray coded) so that a single out-of-position-by-one 
error in the medium, caused, for example, by intersymbol interference, results in only a single bit error in the 
received data, rather than in a multiple bit error. 



Table 69— Sixteen- PPM basic rate mapping 



Data 


16-PPM symbol 


0000 


0000000000000001 


0001 


0000000000000010 


0011 


0000000000000100 


0010 


0000000000001000 


0110 


0000000000010000 


0111 


0000000000100000 


0101 


0000000001000000 


0100 


0000000010000000 


1100 


0000000100000000 


1101 


0000001000000000 


1111 


0000010000000000 


1110 


ooooiooooooooooo 


1010 


- 0001000000000000 


1011 


0010000000000000 


1001 


0100000000000000 


1000 


1000000000000000 



Table 70— Four-PPM enhanced rate mapping 



Data 


4-PPM symbol 


00 


0001 


01 


0010 


11 


0100 


10 


1000 



16.3.2.2 Octet partition and PPM symbol generation procedure 

Since PPM is a block modulation method, with the block size less than a full octet, octets have to be parti- 
tioned prior to modulation (mapping into PPM symbols). 

Octet partition depends on the PPM order being used. 

Assume an octet is formed by eight bits numbered 7 6 5 4 3 2 l 0, where bit 0 is the lsb. Partition the octet as 
follows: 

For 16-PPM, create two PPM symbols: 

— The symbol using bits 3 2 l 0 shall be transmitted onto the medium first. 

— The symbol using bits 7 6 5 4 shall be transmitted onto the medium last. 
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For 4-PPM, create four PPM symbols: 

— The symbol using bits 1 0 shall be transmitted onto the medium first. 

— The symbol using bits 3 2 shall be transmitted onto the medium second. 

— The symbol using bits 5 4 shall be transmitted onto the medium third. 

— The symbol using bits 7 6 shall be transmitted onto the medium last. 

16.3.2.3 Operating environment 

The IR PHY will operate only in indoor environments. IR PHY interfaces cannot be exposed to direct sun- 
light. The IR PHY relies on reflected infrared energy and does not require a line-of-sight between emitter 
and receiver in order to work properly. The range and bit error rate of the system may vary with the geometry 
of the environment and with natural and artificial illumination conditions. 

16.3.2.4 Operating temperature range 

The temperature range for full operation compliance with the IR PHY is specified as 0 °C to 40 °C. 
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16.3.3 PMD transmit specifications 

The following subclauses describe the transmit functions and parameters associated with the PMD sublayer. 
16.3.3.1 Transmitted peak optical power 

The peak optical power of an emitted pulse shall be as specified in Table 71. 



Table 71— Peak optical power as a function of emitter radiation pattern mask 



Emitter radiation 
pattern mask 


Peak optical power 


Mask 1 


2Wi 20% 


Mask 2 


0.55 W ± 20% 



16.3.3.2 Basic pulse shape and parameters 

The basic pulse width, measured between the 50% amplitude points, shall be 250 ± 10 ns. The pulse rise 
time, measured between the 10% and 90% amplitude points, shall be no more than 40 ns. The pulse fall 
time, measured between the 10% and 90% amplitude points, shall be no more than 40 ns. The edge jitter, 
defined as the absolute deviation of.the edge from its correct position, shall be no more than 10 ns. The basic 
pulse shape is shown in Figure 102. 



90% 



50% 



10% 



;40 ns 




250 ns ±10ns 



Jitter ±10 ns 




£40 ns 



litter ±10 ns 



Figure 102— Basic pulse shape 
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16.3.3.3 Emitter radiation pattern mask 

The standard contains two emitter radiation pattern masks. Mask I is defined in Table 72 and illustrated in 
Figure 1 03. Mask 2 is defined in Table 73 and illustrated in Figure 105. 



Table 72— Definition of the emitter radiation pattern mask 1 



Declination angle 


Normalized irradiance 


a<60° 


>3.5X JO' 6 


a<29° 


<2.2x 10" 5 


29 s < a < 43' 


<-l.06x lO^ + tO^x l(T 5 )a 


43*<a<57' 


< LIS x lO^-ai x 10' 7 )a 


57'<a<74* 


<2.98x 10" 4 -(3.9x 10~ 6 )a 


74 e <a<90' 


<4.05x 10" 5 -(4.5x I0~ 7 )a 



Normalized IR-radiance, W/cm 

100 T 

80 
60 

nW/cm' 

40 
20 



0l i i : N i 

0° 10° 20° 30° 40° 50° 60° 70° 80° 90° 

Emitting Angle, Degrees 
Figure 103 — Emitter radiation pattern mask 1 

Following is a description of how to interpret the Mask l table and figure. Position the conformant Mask 1 
device in its recommended attitude. Define the conformant Mask 1 device axis as the axis passing through 
the emitter center and having the direction perpendicular to the floor. The mask represents the irradiance nor- 
malized to the total peak emitted power, as a function of the angle between the conformant Mask 1 device 
axis and the axis from the emitter center to the test receiver center (declination angle). The distance between 
emitter and test receiver is 1 m. The test receiver normal is always aimed at the emitter center. The azimuth 
angle is a rotation angle on the conformant device axis. 

A device is conformant if for any azimuth angle its radiation pattern as a function of declination angle falls 
within the pattern mask. 

Figure 104 is a description of how to interpret the Mask 2 table with reference to Figure 105. 



Maximum 
Minimum 
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Table 73— Definition f emitter radiation pattern mask 2 



Declination angle 


Pitch angle 


Normalized irradiance 


a<60 


a = 0 


0.05 ±15% 


a<90 


a = 0 


0.025 ±15% 


a> 100 


a = 0 


< 0.015 


0 < a < 60 


0<a< 10 


0.035 < I < 0.055 


0 < a < 60 


10<a<20 


0.0225 < I < 0.05 


0 < a < 60 


a>30 


<0.015 




Figure 104 — Mask 2 device orientation drawing 
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Figure 105— Emitter radiation pattern mask 2 
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Position the conformant Mask 2 device in its recommended attitude. Define the conformant Mask 2 device 
axis as passing through the emitter center and having the direction relative to the device as defined by the 
manufacturer. The declination angle plane is as defined by the manufacturer. The mask represents the irradi- 
ance normalized to the peak emitted power on the conformant Mask 2 device axis, as a function of the angle 
between the conformant device axis and the axis from the emitter center to the test receiver center (declina- 
tion angle) in the declination plane. The distance between emitter and test receiver is 1 m. The test receiver 
normal is always aimed at the emitter center. The pitch angle is an angle relative to the conformant device 
axis which is perpendicular to the declination plane. 

The device is conformant if, for a pitch angle of 0 degrees, at any declination angle from 0 to 100 degrees, 
and if, for any declination angle from 0 to 60 degrees,, at any pitch angle from 0 to 20 degrees, its radiation 
pattern as a function of angle falls within the pattern mask. 

Other radiation patterns are for future study. 

16.3.3.4 Optical emitter peak wavelength 

The optical emitter peak wavelength shall be between 850 nm and 950 nm. 

16.3.3.5 Transmit spectrum mask 

Define the transmit spectrum of a transmitter as the Fourier Transform, or equivalent, of a voltage (or cur- 
rent) signal whose amplitude, as a function of time, is proportional to the transmitted optical power. 

The transmit spectrum of a conformant transmitter shall be 20 dB below its maximum for all frequencies 
above 15 MHz. The transmit spectrum mask is shown in Figure 106. 



OdB 

















i 

20 dB at 15 MHz 


r 










i 



0 MHz 15 MHz 

Figure 106 — Transmit spectrum mask 



16.3.4 PMD receiver specifications 

The following subclauses describe the receive functions and parameters associated with the PMD sublayer. 
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16.3.4.1 Receiver sensitivity 

The receiver sensitivity, defined as the minimum irradiance (in mW/cm 2 ) at the photodetector plane required 
for a frame error ratio (FER) of 4x l(T 5 with a PLCSDU of 5 1 2 octets and with an unmodulated background 
IR source between 800 nm and 1 000 nm with a level of 0. 1 mW/cm 2 , shall be 

1 Mbit/s: 2x l0~ 5 mW/cm 2 
2Mbit/s: 8x 10- 5 mW/cm 2 

16.3.4.2 Receiver dynamic range 

The receiver dynamic range, defined as the ratio between the maximum and minimum irradiance at the plane 
normal to the receiver axis that assures an FER lower than or equal to 4 x 1 0~ 5 with a PLCSDU of 5 1 2 octets 
and with an unmodulated background IR source between 800 nm and 1000 nm with a level of 0. 1 mW/cm 2 
shall be >30dB. 

16.3.4.3 Receiver field-of-view (FOV) 

The receiver axis is defined as the direction of incidence of the optical signal at which the received optical 
power is maximum. 

The received optical power shall be greater than the values given in Table 74, at the angles indicated, where 
"angle of incidence" is the angle of the optical signal relative to the receiver axis, and "received power" is 
the received optical power as a percentage of that measured at the receiver axis. 



Table 74 — Definition of the receiver field of view 



Angle of incidence 


Received power 


cc<20° 


> 65% 


oc<40° 


> 55% 


cc<60° 


> 35% 


a<80° 


> 10% 



16.3.5 Energy Detect, Carrier Sense, and CCA definitions 

16.3.5.1 Energy Detect (ED) signal 

The ED signal shall be set true when IR energy variations in the band between l MHz and 10 MHz exceed 
0.001 mW/cm 2 . 

The ED shall operate independently of the CS. The ED shall not be asserted at the minimum signal level 
specified in 16.3.4.1, which is below the level specified in this subclause. 

This signal is not directly available to the MAC. 

16.3.5.2 Carrier Sense (CS) signal 

The CS shall be asserted by the PHY when it detects and locks onto an incoming PLCP Preamble signal. 
Conforming PHYs shall assert this condition within the first 12 us of signal reception, at the minimum signal 
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level equal to the receiver sensitivity specified in 1 6.3.4. 1, with a background IR level as specified in 
16.3.4.1. 

The CS shall be deasserted by the PHY when the receiving conformant device loses carrier lock. 

NOTE — The 12 ^is specification is somewhat less than the minimum length of the PLCP SYNC interval, which is 14.25 ^is. 

The CS shall operate independently of the ED and shall not require a prior ED before the acquisition and 
assertion of CS. This permits reception of signals at the minimum signal level specified in 16.3,4.1, even 
though these signals fall below the ED level. 

This signal is not directly available to the MAC. 

16.3.5.3 CCA 

CCA shall be asserted "IDLE" by the PHY when the CS and the ED are both false, or when ED has been 
continuously asserted for a period of time defined by the product of dotl lCCAWatchdogTimerMax and 
dotl lCCAWatchdogCountMax without CS becoming active. When either CS or ED go true, CCA is indi- 
cated as "BUSY" to the MAC via the primitive PHY-CCA. indicate. CS and DE behavior are defined in 
16.3.5.2. 

Normally, CCA will be held "BUSY" throughout the period of the PLCP Header. After receiving the last 
PLCP bit and the first data octet, the PHY shall signal PHY-RXSTART.indicate with the parameters 
LENGTH and RATE. CCA shall be held "BUSY" until the number of octets specified in the decoded PLCP 
Header are received. At that time the PHY shall signal PHY-RXEND.indicate. The CCA may remain 
"BUSY" after the end of data if some form of energy is still being detected. The PHY will signal PHY- 
CCA.indicate with a value of IDLE only when the CCA goes "CLEAR" 

The transition of CCA from "BUSY" to "IDLE" is indicated to the MAC via the primitive PHY-CCA.indicate. 

If CS and ED go false before the PHY signals PHY-RXSTART.indicate, CCA is set to "IDLE" and immedi- 
ately signaled to the MAC via PHY-CCA.indicate with a value of IDLE. If CS and ED go false after the 
PHY has signaled PHY-RXSTART.indicate, implying that the PLCP Header has been properly decoded, 
then the PHY shall not signal a change in state of CCA until the proper interval has passed for the number of 
octets indicated by the received PLCP LENGTH. At that time, the PHY shall signal PHY-RXEND.indicate 
with an RXERROR parameter of CarrierLost followed by PHY-CCA.indicate with a value of IDLE. 

The transition of CCA from "CLEAR" to "BUSY" resets the CCA watchdog timer and CCA watchdog 
counter, dotl lCCAWatchdogTimerMax and dotl lCCAWatchdogCountMax are parameters available via 
MIB entries and can be read and set via the LME. 

Rise and fall time's of CCA'relative to the OR'ing of the CS and ED signals shall be less than 30 ns. CS and 
ED are both internal signals to the PHY and are not available directly to the MAC, nor are they defined at 
any exposed interface. 

16.3.5.4 CHNLJD 

For the IR PHY, CHNL_ID = X'OT is defined as the baseband modulation method. All other values are not 
defined. 
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16.4 PHY attributes 

PHY attributes have allowed values and default values that are PHY dependent. Table 75 and Table 76 describe 
those values, and further specify whether they are permitted to vary from implementation to implementation. 

Table 75 does not provide the definition of the attributes, but only provides the IR PHY-specific values for 
the attributes whose definitions are in Clause 13. 



Table 7S-IR PHY MIB attributes 



PHY M IB object 


Default value 


Operational 
semantics 


Operational behavior 


dotl lCCAWatchdogTimerMax 


Implementation 
dependent 


Dy nam it- 


A conformant PHY may set this via 
the LME 


dotl ICCAWatchdogCountMax 


Implementation 
dependent 


Dynamic 


A conformant PHY may set this via 
the LME 


dotl iCCAWatchdogTimerMin 


22 us 


Static 


Identical for all conformant PHYs 


dotl lCCAWatchdogCountMin 


1 


Static 


Identical for all conformant PHYs 


dotl lSupportedDataRatesTx 


Implementation 
dependent 


Static 


All conformant PHYs must include 
the value X'02*(l Mbit/s). 


dotl ISupportedData Rates Rx 


Implementation 
dependent 


Static 


All conformant PHYs must include 
the values X'02' ( I Mbit/s) and 
X , 04 , (2 Mbit/s). 


dotl I Phy Type 


03 


Static 


Identical for all conformant PHYs 


dot 1 1 PhyTempType 


X'01' 


Static 


Identical for all conformant PHYs 
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The static IR PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, are 
shown in Table 76. The definitions of these characteristics are in 10.4.3. 



Table 76— IR PHY characteristics 



Characteristic 


Value 


aSlotTime 


8^s 


aSIFSTime 


10 


aCCATime 


5 us 


aRxTxTumaroundTime 


0 us 


aTxPLCPDelay 


Implementors may choose any value for this delay as long as 
the requirements of aRxTxTumaroundTime are met > 


aRxPLCPDelay 


1 us 


aRxTxSwitchTime 


0 us 


aTxRampOnTime 


Ous 


aTxRampOtfTime 


Ous 


aTxRFDelay 


Implementors may choose any value for this delay as long as 
the requirements of aRxTxTumaroundTime are met. 


aRxRFDelay 


Implementors may choose any value for this delay as long as 
the requirements of aSIFSTime and aCCATime are met. 


aAirPropagationTime 


i M s 


a MAC Processing Delay 


2 us 


aPreamble Length 


1 6 ms ( 1 Mbit/s) 
20 us (2 Mbit/s) 


aPLCPHeaderLength 


41 us(t Mbit/s) 
25 \is (2 Mbit/s) 


aMPDUDurationFactor 


0 


aMPDUMaxLength 


2500 


aCWmin 


63 


aCWmax 


1023 
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Annex A 

(normative) 

Protocol Implementation Conformance Statement (PICS) 
proforma 



A.1 Introduction 

The supplier of a protocol implementation that is claimed to conform to ISO/IEC 8302. II: 1999 shall com- 
plete the following PICS proforma. 

A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of 
which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, 
including use 

a) By the protocol implementor, as a checklist to reduce the risk of failure to conform to the standard 
through oversight; 

b) By the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of 
the capabilities of the implementation, stated relative to the common basis for understanding pro- 
vided by the standard PICS proforma; 

c) By the user, or potential user, of the implementation, as a basis for initially checking the possibility 
of interworking with another implementation (note that, while interworking can never be guaran- 
teed, failure to interwork can often be predicted from incompatible PICS proformas); 

d) By a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for 
conformance of the implementation. 



A.2 Abbreviations and special symbols 

A.2.1 Status symbols 

M mandatory 
O optional 

0.<n> optional, but support of at least one of the group of options labeled by the same numeral <n> 
is required 

pred: conditional symbol, including predicate identification 



A.2.2 General abbreviations 



N/A 


not applicable 


AD 


address function capability 


CF 


implementation under test (IUT) configuration 


FR 


MAC frame capability 


FS 


frame sequence capability 


PC 


protocol capability 


PICS 


protocol implementation conformance statement 
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A.3 Instructions for completing the PICS proforma 
A.3.1 General structure of the PICS proforma 

The first part of the PICS proforma, Implementation identification and Protocol summary, is to be completed 
as indicated with the information necessary to identify fully both the supplier and the implementation. 

The main part of the PICS proforma is a fixed questionnaire, divided into subclauses, each containing a 
number of individual items. Answers to the questionnaire items are to be provided in the rightmost column, 
either by simply marking an answer to indicate a restricted choice (usually Yes or No) or by entering a value 
or a set or a range of values. (Note that there are some items where two or more choices from a set of possi- 
ble answers may apply. All relevant choices are to be marked in these cases.) 

Each item is identified by an item reference in the first column. The second column contains the question to 
be answered. The third column contains the reference or references to the material that specifies the item in 
the main body of ISO/IEC 8802-11: 1999. The remaining columns record the status of each item, i.e., 
whether support is mandatory, optional, or conditional, and provide the space for the answers (see also 
A.3. 4). Marking an item as supported is to be interpreted as a statement that all relevant requirements of the 
subclauses and normative annexes, cited in the References column for the item, are met by the implementa- 
tion. 

A supplier may also provide, or be required to provide, further information, categorized as either Additional 
Information or Exception Information. When present, each kind of further information is to be provided in a 
further subclause of items labeled A<1> or X<1>, respectively, for cross-referencing purposes, where </> is 
any unambiguous identification for the item (e.g., simply a numeral). There are no other restrictions on its 
format or presentation. 

The PICS proforma for a station consists of A.4.1 through A.4.4 inclusive, and at least one of A. 4.5, A.4.6, 
or A.4.7 corresponding to the PHY implemented. 

A completed PICS proforma, including any Additional Information and Exception Information, is the PICS 
for the implementation in question. 

NOTE — Where an implementation is capable of being configured in more than one way, a single PICS may be able to 
describe all such configurations. However, the supplier has the choice of providing more than one PICS, each covering 
some subset of the implementation's capabilities, if this makes for easier and clearer presentation of the information. 

A.3.2 Additional information 

Items of Additional ^formation allow a supplier to provide further information intended to assist in the 
interpretation of the PICS. It is not intended or expected that a large quantity of information will be supplied, 
and a PICS can be considered complete without any such information. Examples of such Additional Infor- 
mation might be an outline of the ways in which an (single) implementation can be set up to operate in a 
variety of environments and configurations, or information about aspects of the implementation that are out- 
side the scope of this standard but have a bearing upon the answers to some items. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and 
may be included in items of Exception Information. 
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A.3.3 Exception information 

It may happen occasionally that a supplier will wish to answer an item with mandatory status (after any con- 
ditions have been applied) in a way that conflicts with the indicated requirement. No preprinted answer will 
be found in the Support column for this. Instead, the supplier shall write the missing answer into the Support 
column, together with an X</> reference to an item of Exception Information, and shall provide the appro- 
priate rationale in the Exception Information item itself. 

An implementation for which an Exception Information item is required in this way does not conform to 
ISO/IEC 8802-11: 1999. 

NOTE— A possible reason for the situation described above is that a defect in ISO/IEC 8802-11: 1999 has been 
reported, a correction for which is expected to change the requirement not met by the implementation. 

A.3.4 Conditional status 

The PICS proforma contains a number of conditional items. These are items for which both the applicability 
of the item itself, and its status if it does apply, mandatory or optional, are dependent upon whether or not 
certain other items are supported. 

Where a group of items is subject to the same condition for applicability, a separate preliminary question 
about the condition appears at the head of the group, with an instruction to skip to a later point in the ques- 
tionnaire if the Not Applicable (N/A) answer is selected. Otherwise, individual conditional items are indi- 
cated by a conditional symbol in the Status column. 

A conditional symbol is of the form "<pred>:<S>", where "<pred>" is a predicate as described below, and 
"<S>" is one of the status symbols M or O. 

If the value of the predicate is true, the conditional item is applicable, and its status is given by S: the support 
column is to be completed in the usual way. Otherwise, the conditional item is not relevant and the N/A 
answer is to be marked. 

A predicate is one of the following: 

a) An item-reference for an item in the PICS proforma: the value of the predicate is true if the item is 
marked as supported, and is false otherwise. 

b) A boolean expression constructed by combining item-references using the boolean operator OR: the 
value of the predicate is true if one or more of the items is marked as supported, and is false otherwise. 

Each item referenced in a predicate, or in a preliminary question for grouped conditional items, is indicated 
by an asterisk in the Item column. 
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A.4 PICS proforma— ISO/IEC 8802-11: 1999 7 



A.4.1 Implementation identification 



Supplier 




Contact point for queries about the PICS 




Implementation Name(s) and Version(s) 




Other information necessary for full identification, e.g., 
name(s) and version(s) of the machines and/or operating 
systems(s), system names 





NOTES 

1 — Only the first three items are required for all implementations. Other information may be completed as appropriate in 
meeting the requirement for full identification. 

2— The terms Name and Version should be interpreted appropriately to correspond with a supplier's terminology (e.g., 
Type, Series, Model). 



A.4.2 Protocol summary, ISO/IEC 8802-11: 1999 



Identification of protocol standard 


ISO/IEC 8802-11: 1999 


Identification of amendments and corrigenda to this 
PICS proforma that have been completed as part of this 
PICS 


Amd. : Corr. : 
Amd. : Corr. 


Have any exception items been required? 
(See A. 3. 3: the answer Yes means that the implementa- 
tion does not conform to ISO/IEC 8802- 1 1 : 1 999.) 


Yes □ No □ 



Date of statement (dd/mm/yy) 



Copyright release for PICS proforma: Users of this standard may freely reproduce the PICS proforma in this annex so that it can be 
used for its intended purpose and may further publish the completed PICS. 
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A.4.3 IUT configuration 



Item 


IUT configuration 


References 


Status 


Support 




What is the configuration of the IUT? 








*CFl 


Access Point (AP) 


5.2 


O.I 


Yes □ No Q 


*CF2 


Independent station {not an AP) 


5.2 


O.l 


Yes □ No □ 


*CF3 


Frequency- Hopping spread spectrum 
<FHSS) PHY for the 2.4 GHz band 




0.2 


Yes Q No □ 


*CF4 


Direct Sequence Spread Spectrum 
( DSSS) PHY for the 2.4 GHz band 




0.2 


Yes □ No □ 


*CF5 


Infrared PHY 




0.2 


Yes □ No □ 



A.4.4 MAC protocol 

A.4.4.1 MAC protocol capabilities 



Item 


Protocol capability 


References 


Status 


Support 




Are the following MAC protocol capabilities 
supported? 








PCI 


Authentication service 


5.4.3.1, 
5.4.3.2, 
5.7.6,5.7.7, 
8.1, AnnexC 


M 


Yes □ No □ 


PCU 


Authentication state 


5.5 


M 


Yes □ No Q 


PCi.2 


Open System authentication 


8.1.1 


M 


Yes □ No □ 


PCI. 3 


Shared Key authentication 


8.1.2, 8.3 


PC2:M 


Yes □ No □ N/A □ 


*PC2 


WEP algorithm 


5.4.3.3, 8.2, 
Annex C 


O 


Yes □ No □ 


- PC2.I 


WEP Encryption procedure 


8.2.3, 8.2.4, 
8.2.5 


PC2:M 


Yes □ No □ N/A □ 


PC2.2 


WEP Decryption procedure 


8.2.3, 8.2.4, 
8.2.5 


PC2:M 


Yes □ No □ N/A □ 


PC2.3 


Security services management 


8.3 


M 


Yes □ No □ 


PC3 


Distributed Coordination function 


9.1,9.2, 
AnnexC 


M 


Yes 0 No a 


PC3.I 


Net Allocation Vector (NAV) 
function • 


9.2.1,9.2.5, 
9.3.2.2 


M 


Yes □ No □ 


PC3.2 


Interframe space usage and timing 


9.2.3,9.2.5, 
9.2.10 


M 


Yes Q No □ 


PC3.3 


Random Backoff function 


9.2.4 


M 


Yes □ No □ 


PC3.4 


DC F' Access procedure 


9.2.5.1, 
9.2.5.5 


iM 


Yes Q No □ 


PC3.5 


Random Backoff procedure 


9.2.5.2 


M 


Yes Q No □ 


PC3.6 


Recovery procedures and 
retransmit limits 


9.2.5.3 


M 


Yes □ No □ 


PC3.7 


RTS/CTS procedure 


9.2.5.4, 
9.2.5.6, 
9.2.5.7 


M 


Yes □ No □ 
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A.4.4.1 MAC pr tocol capabilities (continued) 



Item 


Protocol capability 


References 


Status 


Support 


PC3.8 


Directed MPDU transfer 


9.2.6 


M 


Yes □ No □ 


PC3.9 


Broadcast and multicast MPDU 
transfer 


9.2.7 


M 


Yes □ No □ 


PC3.10 


MAC level acknowledgment 


9.2.2, 
9.2.8 


M 


Yes □ No □ 


PC3.ll 


Duplicate detection and recovery 


9.2.9 


M 


Yes □ No □ 


*PC4 


Point coordinator (PC) 


9.1,9.3, 
Annex C 


CFI:0 


Yes □ No □ N/A □ 


PC4.1 


Maintenance of CFP structure 
and timing 


9.3.1,9.3.2 


PC4:M 


Yes □ No □ N/A □ 


PC4.2 


PCF MPDU transfer from PC 


9.3.3 


PC4:M 


Yes □ No □ N/A □ 


* PC4.3 


PCF MPDU transfer to PC 


9.3.3 


PC4:0 


Yes □ No □ N/A □ 


PC4.4 


Overlapping PC provisions 


9.3.3.2 


PC4:M 


Yes Q No □ N/A □ 


PC4.5 


Polling list maintenance 


9.3.4 


PC4.3: 
M 


Yes □ No □ N/A □ 


*PC5 


CF-Pollable 


9.1,9.3, 
Annex C 


CF2:0 


Yes □ No □ N/A □ 


PC5.1 


Interpretation of CFP structure 
and timing 


9.3.1,9.3.2 


PC5:M 


Yes □ No □ N/A □ 


PC5.2 


PCF MPDU transfer to/from 
and CF-Pollable STA 


9.3.3 


PC5:M 


Yes □ No □ N/A □ 


PC5.3 


Polling list update 


9.3.4 


PC5:M 


Yes □ No □ N/A □ 


PC6 


Fragmentation 


9.2, 9.4, 
Annex C 


M 


Yes □ No □ 


PC7 


De fragmentation 


9.2, 9.5, 
Annex C 


M 


Yes □ No □ 


PC8 


MAC data service 


9.1.5, 9.8, 
Annex C 


M 


Yes □ No □ 


PC8.1 


Reorderable- Multicast service class 


9.8 


M 


YesO No □ 


PC8.2 


Strictly Ordered service class 


9.8 


0 


Yes Q No □ 


PC9 


Multirate support 


9.6, 

Annex C 


M 


Yes □ No □ 


*PC10 


Multiple outstanding MSDU support 


9.8, 

Annex C 


0 


Yes □ No □ 


pc i o. i 


Multiple outstanding MSDU 
transmission restrictions 


9.8 


PC10:M 


Yes □ No □ N/A □ 


PCll 


Timing synchronization 


II. 1, 
Annex C 


M 


Yes □ No □ 


PCtl.l 


Timing in an infrastructure 
network 


11. 1.1.1, 
11.1.4 


CF1:M 


Yes □ No □ N/A □ 


PCM.2 


Timing in an Independent BSS 
(IBSS) 


11.1.1.2, 
11.1.4 


CF2:M 


Yes □ No □ N/A □ 


PCI 1.3 


Beacon Generation function 


It. 1.2 


M 


Yes □ No □ N/A □ 


PCI 1.5 


TSF synchronization and accuracy 


11.1.2 


M 


Yes □ No □ 


PCI 1.5 


Infrastructure BSS initialization 


11.1.3 


CF1:M 


Yes □ No □ N/A □ 
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A.4.4.1 MAC protocol capabilities (continued) 



Item 


Protocol capability 


References 


Status 


Support 


PCI 1.6 


Independent BSS initialization 


11.1.3 


CF2:M 


Yes □ No Q N/A Q 


PCI 1.7 


Passive scanning 


1 1.1.3 


CF2:M 


Vpc Q Mr* n N/A f~i 

I Cb 1NO J IN/ /\ J 


PCI 1.8 


Active scanning 


1 1.1.3 


CF2:M 


Yes □ No Q N/A □ 


pcn.9 


Probe response 


1 1.1.3 


M 


Yes □ No O 


PC 1 1 . 1 0 


Hop Synchronization function 


11. 1.5 


CF3:M 


Yes □ Nln Q N/A H 

Its U IN KJ l >J IN/ /A 


PC12 


Infrastructure power management v 


1 1.2. 1, 
Annex C 


M 


Vpc n Mo n 


PC12.1 


Station power management modes 


11.2.1.1, 
11.2.1.8 


CF2:M 


Yes □ No Q N/A Q 


PC12.2 


TIM transmission 


11.2.1.2, 
11.2.1.3 


CFl:M 


Yes □ No □ N/A □ 


PC 1 2.3 


AP function during CP 


11.2.1.4 


CF!:M 


Yes □ No □ N/A □ 


PC 1 2.4 


AP function during CFP 


11.2.1.5 


PC4:M 


Yes □ No Q N/A □ 


PC 12.5 


Receive function during CP 


11.2.1.6 


CF2:M 


Yes □ No □ N/A □ 


PC 12.6 


Receive function during CFP 


11.2.1.7 


PC5:M 


Yes □ No □ N/A □ 


PC12.7 


Aging function 


11.2.1.9 


CF!:M 


Yes □ No □ N/A □ ■ 


PC13 


IBSS power management 


11.2.2, 
Annex C 


CF2:M 


Yes □ No □ N/A □ 


PC13.1 


Initialization of power 
management 


1 1.2.2.2 


CF2:M 


Ypc □ Nn !~i N/A n 
ICsU INQ IN/ A. 'J 


PC13.2 


STA power state transitions 


11.2.2.3 


CF2:M 


Yes □ No □ N/A □ 


PC13.3 


ATIM and frame transmission 


11.2.2.4 


CF2:M 


Yes □ No □ N/A □ 


PC14 


Association and reassociation 


5.4, 5.7, 
11.3, 
Annex C 


M 


Yes □ No □ 










PC14.1 


Association state 


5.5 


M 


Yes □ No □ 


PC14.2 


STA association procedure 


1 1.3.1 


CF2:M 


Yes □ No □ N/A □ 


PC 14.3 


AP association procedure 


11.3.2 


CFI:M 


Yes □ No □ N/A □ 


PC14.4 


STA reassociation procedure 


11.3.3 


CF2:M 


Yes □ No □ N/A □ 


PC14.5 


AP reassociation procedure 


U.3.4 


CF1:M 


Yes □ No Q N/A □ 


PC15 


Management information base (MIB) 


Annex D 


M 


Yes Q No □ 


PC15.1 


dotllSMTbase, 

dotl ISmtAuthenticat ion Algorithms 


Annex D 


M 


Yes □ No □ 


* PCI5.2 


dotl ISMTprivacy 


Annex D 


PC2:M 


Yes Q No □ N/A Q 


PC 1 5.3 


dotl IMACbase, dotl ICountersGroup, 
dotl IMacGroupAddresses 


Annex D 


M 


Yes □ No Q 


* PC15.4 


dotl IMACStatistics 


Annex D 


0 


Yes Q No □ 


PC15.5 


dot 1 1 ResourceTypelD 


Annex D 


M 


Yes □ No □ 
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A.4.4.2 MAC fram s 



Item 


iMAC frame 


References 


Status 


Support 




Is transmission of the following 
MAC frames supported? 


7, Annex C 






FT1 


Association request 


7 


CF2:M 


Yes □ No □ N/A □ 


FT2 


Association response 


7 


CF1:M 


Yes □ No □ N/A Q 


FT3 


Reassociation request 


7 


CF2:M 


Yes □ No □ N/A □ 


FT4 


Reassociation response 


7 


CFl:M 


Yes □ No □ N/A □ 


FT5 


Probe request 


7 


CF2:M 


Yes □ No □ N/A □ 


FT6 


Probe response 


7 


M 


Yes □ No Q 


FT7 


Beacon 


7 


M 


Yes □ No □ 


FT8 


ATIM 


7 


CF2:M 


Yes □ No □ N/A Q 


FT9 


Disassoctation 


7 


M 


Ypc Q No □ 


FT10 


Authentication 


7 


M 


Yes Q No Q 


FTU 


Deauthentication 


7 


M 


Yes □ No □ 


FT12 


PS-Poll 


7 


CF2:M 


Yes □ No □ N/A □ 


FT13 


RTS 


7 


M 


Yes □ No □ 


FT14 


CTS 


7 


M 


Yes □ No □ 


FT15 


ACIC 


7 


M 


Yes □ No □ 


FT16 


CF-End 


7 


PC4:M 


Yes □ No □ N/A □ 


FT17 


CF End+CF-Ack 


7 


PC4:M 


Yes □ No □ N/A □ 


FT18 


Data 


7 


M 


Yes □ No □ 


FT19 


Data + CF-Ack 


7 


(PC4 OR 
PC5):M 


Yes □ No □ N/A □ 


FT20 


Data + CF-Poll 


7 


PC4.3:M 


Yes □ No □ N/A □ 


FT21 


Data + CF-Ack+CF-Poll 


7 


PC4.3:M 


Yes □ No □ N/A □ 


FT22 


Null 


7 


M 


Yes □ No □ 


FT23 


CF-Ack (no data) 


7 


(PC4 OR 
PC5):M 


Yes □ No □ N/A □ 


FT24 


CF-Poll (no data) 


7 


PC4.3:M 


Yes □ No □ N/A □ 


FT25 


CF-Ack+CF-Poll (no data) 


7 


PC4.3:M 


Yes □ No □ N/A □ 




Is reception of the following MAC 
frames supported? 


7, Annex C 






FR1 


Association request 


7 


CF1:M 


Yes □ No □ N/A □ 


FR2 


Association response 


7 


CF2:M 


Yes □ No □ N/A □ 


FR3 


Reassociation request 


7 


CFl:M 


Yes □ No □ N/A □ 


FR4 


. Reassociation response 


7 


CF2:M 


Yes □ No □ N/A □ 


FR5 


Probe request 


7 


M 


Yes □ No □ 


FR6 


Probe response 


7 


M 


Yes □ No □ 


FR7 


Beacon 


7 


M 


Yes □ No □ 


FR8 


ATIM 


7 


CF2:M 


Yes □ No □ N/A □ 


FR9 


Disassociation 


7 


M 


Yes □ No □ 


FRIO 


Authentication 


7 


M 


Yes □ No □ 
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A.4.4.2 MAC frames (continued) 



Item 


MAC frame 


References 


Status 


Support 


FRl I 




Deauthentication 




? 


M 


Ve< D Nln Q 
I ts w INU 


FR12 




PS-Poll 




? 


CFl:<M 


Vpq O Wr» H Nl/A n 

I CS 1N(J »J IN/ f\ J 


FR13 




RTS 




? 


M 




FR14 




CTS 




? 


M 


Yes □ Nn Q 


FR15 




ACK 




' 


M 


Yes □ No □ 


FR16 




CF-End 




7 


M 


Yes □ No □ 


FRI7 




CF End+CF-Ack 




7 


M 


Yes □ No Q 


FR18 




Data 






M 


Yes Q No □ 


FRI9 




Data + CF-Ack 






M 


Yes □ No □ 


FR20 




Data + CF-Poll 






PC5:M 


Yes □ No Q N/ A Q 


FR21 




Data + CF-Ack+CF-Poll 






PC5:M 


Yes Q No □ N/A □ 


FR22 




Null 






M 


Yes □ No □ 


FR23 




CF-Ack (no data) 






(PC4 OR 
PC5):M 


Yes □ No □ N/A □ 


FR24 




CF-Poll (no data) 






PC5:M 


Yes □ No □ N/A □ 


FR25 




CF-Ack+CF-Potl (no data) 






PC5:M 


Yes □ No □ N/A □ 


A.4.4.3 Frame exchange sequences 


Item 


Frame exchange sequence 


References 


Status 


Support 




Axe the following frame sequences 
supported? 










FS1 


Basic frame sequences 


9.7, Annex C 


M 


Yes □ No □ 


FS2 


CF- Frame sequences 


9.7, Annex C 


(PC4 ORPC5):M 


Yes □ No □ N/A □ 



A.4.4.4 MAC addressing functions 



Item 


MAC Address function 


References 


Status 


Support 




Are the following MAC Addressing 
functions supported? 








AD1 


STA universal individual 
. IEEE.802-address 


5.3.3, 
7.1.3.3 


M 


Yes □ No □ 


AD 2 


BSS identifier generation 


7.1.3.3, 
11.1.3, 
Annex C 


M 


Yes □ No □ 


AD3 


Receive address matching 


7.1.3.3, 
7.2.2, 
Annex C 


M 


Yes □ No □ N/A □ 
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A.4.5 Frequency-Hopping PHY functions 



Item 


Protocol feature 


References 


Status 


Support 




Which requirements and options does the 

DUV flinnnrt') 

rrti SUppon/ 








rni 


PHY service primitive parameters 








PU t 1 
r ri 1 . 1 


l AVhL l UK parameter: LhNO I n 


14.2.2.1 


M 


Yes □ No □ 


rni.4 


TYVCrT^D nnnmotof D ( PDQITD ATC 

i avcl i\jk parameter. rLL,roi i kai t 


1 A *> *> 

14.Z.Z.Z 


M 


Yes LI No U 


rni.4.1 


PI PPHfTD ATP — Y*f|/V / 1 A Nylk;*/^ 
rLCrtJL 1 KAI t - AUU ( l.U ivlDlVSj 


1 A "> ~i T 


\A 

M 


Yes U No U 


rril.z.z 


rLLrbl 1 KAI h — A \)l (z.U Mblt/s) 


14.2.2.2 


0 


Yes Q No □ 


FH1.3 


RXVECTOR parameter LENGTH 


14.2.3.1 


M 


Yes □ No □ 


FH1.4 


RXVECTOR parameter: RSSI 


14.2.3.2 


0 


Yes □ No □ 


FH2 


PLCP frame format 








FH2.1 


PLCP Preamble: Sync 


14.3.2.1.1 


M 


Yes □ No □ 


FH2.2 


PLCP Preamble: Start Frame Delimiter 


14.3.2.1.2 


M 


Yes □ No □ 


FH2.3 


PLCP Header: Length Word 


14.3.2.2.1 


M 


Yes □ No □ 


FH2.4 


PLCP Header: Signaling field 


14.3.2.2.2 


M 


Yes □ No □ 


FH2.5 


PLCP Header: Header Error Check 


14.3.2.2.3 


M 


Yes □ No □ 


FH2.6 


PLCP Data Whitener: Scrambling and 
bias suppression encoding 


14.3.2.3, 
14.3.3.1.1 


M 


Yes □ No □ 


FH3 


PLCP Transmit procedure 








rnJ. 1 


Transmit: transmit on MAC request 


14.3.3.1. 1 


M 


Yes □ No □ 




Transmit: format and whiten frame 


14.3.3. 1. 1 


M 


Yes □ No □ 


FH3.3 


Transmit: Timing 


14.3.3.1.1 


M 


Yes □ No □ 


FH4 


PLCP CS/CCA procedure 








FH4.1 


CS/CCA: perform on a minimum of one 
antenna 


14.3.3.2.1 


M 


Yes □ No □ 


FH4.2. 


CS/CCA: Detect preamble starting up to 
20 |i.s after start of slot time 


14.3.3.2.1 


M 


Yes □ No □ 


r n4,j 


tj/v^CA. ueteci preamoie starting at 
least 16 jxs prior to end of slot time 




M 


Yes U No LJ 


FH4.4 


CS/CCA: Detect random data 


14.3.3.2.1 


M 


Yes □ No □ 


FH4.5 


CS/CCA: Perform on antenna with 
essentially same gain and pattern as 

transmit nntf*nna 


14.3.3.2.1 


M 


Yes □ No □ 


FH4.6 


CS/CCA: Detect valid SFD and PLCP 
header 


14.3.3.2.1 


M 


Yes □ No □ 


FH4.7 


CS/CCA: Maintain BUSY indication 
until end of length contained in valid 
PLCP header 


14.3.3.2.1 


M 


Yes □ No □ 


FH5 


PLCP Receive procedure 








FH5.1 


Receive: Receive and dewhiten frame 


14.3.3.3.1 


M 


Yes □ No □ 


FH6 


PHY LME 








FH6.I 


PLME: Support FH sync 


14.4.2.2 


M 


Yes □ No □ 


FH6.2 


PLME: Support PLME primitives 


14.4.3.2 


0 


Yes □ No □ 
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A.4.5 Frequency-Hopping PHY functions (continued) 



Item 


Protocol feature 


References 


Status 


Support 


FH7 


Geographic area specific requirements 








* FH7.1 


Geographic areas 








FH7.I.1 


North America 


14.6.2 


O.l 


Yes □ No Q 


FH7.1.2 


Most of Europe 


14.6.2 


O.I 


Yes □ No Q 


FH7.1.3 


Japan 


14.6.2 


O.l 


Yes Q Nn □ 


FH7.I.4 


Spain 


14.6.2 


O.l 


Yes □ Nn Q 


FH7.1.5 


France 


1 'r.O.i 


\J. 1 


Yes U No U 


FH7.2 


Operating frequency range 


14.6.3 


FH7.1:M 


Yes Q No □ 


FH7.3 


Number of operating channels 


14.6.4 


FH7.l:M 


Yes Q No □ 


FH7.4 


Operating channel frequencies 


14.6.5 


FH7. l:M 


Yes Q No Q 


FH7.5 


Occupied channel bandwidth 


14.6.6 


FH7.1:M 


Yes □ No □ 


FH7.6 


Minimum hop rate 


14.6.7 


FH7.i:M 


Yes □ No Q 


FH7.7 


Hop sequences 


14.6.8 


FH7.LM 


Yes □ No □ 


FH7.8 


Unwanted emissions 


14.6.9 


FH7.1:M 


Yes □ No □ 


FH8 


I Mbit/s PMD 








FH8.1 


Modulation 2GFSK, BT=0.5, ^positive 
frequency deviation, 0=negative 
frequency deviation 


14.6.10 


M 


Yes Q No □ 


FH8.2 


Peak frequency deviation 


14.6.10 


M 


Yes □ No □ 


FH8.3 


Zero-Crossing error 


14.6.10 


M 


Yes □ No □ 


FH8.4 


Nominal channel data rate 


14.6.11 


M 


Yes □ No □ 


FH8.5 


Channel switching/settling time 


14.6.12 


M 


Yes □ No □ 


FH8.6 


Receive to transmit switch time 


14.6.13 


M 


Yes □ No □ 


FH8.7 


Nominal transmit power 


14.6.14.1 


M 


Yes □ No □ 


FH8.8 


Transmit power levels 


14.6.14.2 


M 


Yes □ No □ 


FH8.9 


Transmit power level control to 
<100 mW 


14.6.14.3 


M 


Yes □ No □ 


FH8.10 


Transmit spectrum shape 


14.6.14.4 


M 


Yes Q No Q 


FH8.ll 


Transmit center frequency tolerance 


14.6.14.5 


M 


Yes □ No □ 


FH8.12 


Transmitter ramp periods 


14.6.14.6 


M 


Yes Q No □ 


FH8.13 


Receiver input dynamic range 


14.6.15.1 


M 


Yes □ No □ 


FH8.14 


Receiver center frequency acceptance 
range 


14.6.15.2 


M 


Yes □ No □ 


r no. i j 


Clear channel assessment power thresh- 
old for a probability of detection of 90% 
( preamble )/70% (random data) for 100 
mW units 


14.0. 1 J.J 


\A 

M 


Yes U No U 


FH8.I6 


Clear channel assessment power thresh- 
old for units >100 mW: sensitivity 
threshold is 1/2 dB lower for every dB 
above 20 dBm 


14.6.15.3 


M 


Yes □ No □ 


FH8.17 


Minimum receiver sensitivity at 
FER=3% with 400 octet frames 


14.6.15.4 


M 


Yes □ No □ 


FH8.18 


I nte modulation protection 


14.6.15.5 


M 


Yes □ No □ 
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A.4.5 Frequency-Hopping PHY functions (continued) 



Item 


Protocol feature 


References 


Status 


Support 


FH8.19 


PW» c p n c 1 1 1 t 1 * ti r\ n 


1 A A 1 < A 
L4.0. 1 J.O 


lVI 


Yes LJ NO LJ 


FH8.20 


Onprntino tpmnprntiirp runup 


1 4 A 1 fs 
ll.O. ID 


\A 
M 


\Ci> LJ INO LJ 


FH8.20.1 


Temperature type I 


14.6.16 


\j 


Vpc ^ Ma i~l 
ICS ^ INO ^ 


FH8.20.2 


Temperature type 2 


14.6.16 


0 


Yes □ No □ 


FH8.20.3 


Temperature type 3 


14.6.16 


0 


Yes □ No □ 


FH9 


2 Mbit/s PMD 








FH9.1 


All 1M PMD requirements 


14.7.1 


FH1.2.2:M 


Yes □ No □ N/A □ 


FH9.2 


Modulation 4GFSK, BT=0.5 


14.7.2 


FHI.2.2:M 


Yes □ No □ N/A □ 


FH9.3 


Frame structure for 2M PHY 


14.7.2.1 


FHl.2.2:M 


Yes □ No □ N/A □ 


FH9.4 


Nominal channel data rate 


14.7.3 


FHl.2.2:M 


Yes □ No □ N/A □ 


FH9.5 


Input dynamic range 


14.7.4 


FH1.2.2:M 


Yes □ No □ N/A □ 


FH9.6 


Minimum receiver sensitivity at 
FER=3% with 400 octet frames 


14.7.5 


FH1.2.2:M 


Yes □ No □ N/A □ 


FH9.7 


Intermodulation protection 


14.7.6 


FH1.2.2:M 


Yes □ No □ N/A □ 


FH9.8 


Desensitization 


14.7.7 


FH1.2.2:M 


Yes □ No □ N/A □ 


FHLO 


MIB 


13.1, 14.8, 
Annex D 


M 


Yes □ No □ 


FH10.1 


dotl lPhyFHSSComplianceGroup, 
dot I lPhyRegDomainsSupportGroup, 
and 

dot 1 1 PhyOperationComplianceGroup 


13.1,14.8 


M 


Yes □ No □ 



A.4.6 Direct sequence PHY functions 



Item 


PHY feature 


References 


Status 


Support 




PLCP sublayer procedures 


15.2 






DSl 


Preamble prepend on TX 


15.2.1 


M 


Yes □ No □ 


DS1.1 


PLCP frame format 


15.2.2, 15.2.3 


M 


Yes □ No Q 


DSl. 2 


PLCP integrity check generation 


15.2.3, 15.2.3.6 


M 


Yes □ No □ 


DSl. 3 


TX rate change capability 


15.2.3.3, 15.2.5 


M 


Yes □ No □ 


DSl. 4 


Supported data rates 


15.1, 15.2.3.3 


M 


Yes □ No □ 


DSl. 5 


Data whitener scrambler 


15.2.4 


M 


Yes □ No □ 


DSl. 6 


Scrambler initialization 


15.2.4 


M 


Yes □ No □ 


DS2 


Preamblerprocess on RX 


15.2.1 






DS2.1 


PLCP frame format 


15.2.2, 15.2.3 


M 


Yes □ No □ 


DS2.2 


PLCP integrity check verily 


15.23, 15.2.3.6 


M 


Yes □ No □ 


DS2.3 


RX Rate change capability 


15.2.3.3, 15.2.5 


M 


Yes □ No □ 


DS2.4 


Data whitener descrambler 


15.2.4 


M 


Yes □ No □ 


DS3 


PN code sequence 


15.4.6.3 


M 


Yes □ No Q 


DS4 


Chipping continue on power down 


15.2.6 


O 


Yes □ No □ 


*DS5 


Operating channel capability 


15.2.6, 15.4.6.2 
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A.4.6 Direct s quence PHY functions (continued) 



Item 


PHY feature 


References 


Status 


Support 


* DS5.1 


North America (FCC) 


1 S 2 ft 1 S 4 ft 1 




ie*> 'J (no 'J IN/ A J 


DS5.1.I 


channel 1 


K 2 f\ 1 S & 6 2 


Uoj. 1 .iVl 


Yes LI No LI N/A LJ 


DS5.I.2 


channel 2 


1 5 2 ft 1 5 4 ft 2 


n^s i m 

l/oj. i .ivi 


ies w rso n/a LJ 


DS5.1.3 


channel 3 


1 S 2 A 1 S 4 62 


l/JJ, t .LVI 


ies LJ NO LJ N/A LJ 


DS5.1.4 


channel 4 


1 S 2 A 1^462 


HQS 1 -Vf 


Yes LJ NO LJ N/A LJ 


DS5.1.5 


channel S 


1 « 7 ft K 4 £ -) 


p\C c 1 . \A 


V/—-. | k k|„ I — | It If A ( 1 

Yes LI No LI N/A LJ 


DS5. 1.6 


V.I14JU1C1 O 




uz>j. 1 .M 


\/_ _ / 1 V|_ | 1 V. 1 / » 1 1 

Yes U No LJ N/A LI 


DS5.1.7 


lilclIlilCl / 




r\c c t *\a 


\/__ ) — k VI~ 1 — i Kl/ A 1 — k 

Yes U No U N/A LJ 


DS5. 1.8 


f h n n n 1 ft 


1 « 7 ft i c a ft 0 


Ui>5. 1 :M 


Yes LJ No U N/A U 


DS5.1.9 


channel 0 


1 < 7 ft 1 « A ft 7 


PiC c 1 . \A 


Yes LI No LI N/A U 


DS5.1.I0 


rhint^pl 1 ft 


1 < 7 ft 1 C /l ft 7 


Uoj. 1 .ivl 


Viir ( — 1 K [ ~ 1 1 V I / A 1 1 

Yes LJ No Li N/A LJ 


UOJ. 1 . t I 


channel 1 1 


lO.z.O, O.4.0.Z 


DS5. 1 :M 


Yes UNou N/A □ 


* DS5.2 




1 < 7 ft 1 < A ft *> 




Yes LI No U N/A Q 


DS5.2.t 


LHoJUlCl I 


l < 7 ft 1 < /t ft 7 




\/„ _ 1 — | V 1 - 1 1 KIM i b 

Yes LI No LI N/A LJ 


DS5.2.2 




1 < 7 ft i < ,£ ft 7 


r\C < 7.\4 


icb Li No Li N/A LJ 


DS5.2.3 


UldlLIlCl J 


1 c 7 ft 1 < d ft 7 

O.Z.O, IO.4.0.Z 


rvc< 7.\/i 


Yes LJ No LJ N/A Li 


DS5.2.4 


UldlLIlCl t 


i c 7 ft i c J ft -> 
IJ.Z.O, 1D.4.0.Z 


p\C c 7, \A 


Yes LJ No LJ N/A LI 




channel 5 


1 ^ 7 ft 1 < /t t "> 
O.Z.O, iJ.H.O.Z 


DS5.2:M 


Yes LI No LI N/A LI 


DS5.2.6 


wlldllllCl O 


1 ^ 7 ft 1 < A ft 7 
1 J.Z.O, 1 3.4.0. 


pvC < 7.\4 


1 1 K 1 — 1 1 VI / A 1 1 

Yes LJ No LI N/A LI 


DS5.2.7 


c nnnn*»l "7 

dldlillCl / 


IO £ 1 C /I ft 7 




Yes LJ No LJ N/A LI 


DS5.2.8 


liliulUlCl O 


1 C 7 ft i c A ft 7 


P|C c 7. \4 


YeS LJ NO LJ N/A LJ 


DS5.2.9 


channel Q 


1 < 7 ft 1 < A ft 7 
1J.Z.O, 1J.4.0.Z 


nc 7-M 
Lfj J . Z . ivl 


ies LJ INO LJ N/A LJ 


DS5.2.10 


channel 1 0 


1 « 7 ft 1 C A ft 7 


HQS 7-M 


V»tr ( i Kfn 1 i XI/ A I — 1 

Yes LJ INO LJ N/A LJ 


DS5.2.1 1 


channel 1 1 


1 « 7 ft 1 c 4 ft 7 


UoJ.Z.iVI 


Vat- 1 \ Klrt 1 1 XI/ A 1 — 1 

YeS LJ NO LJ N/A LJ 


* DS5.3 


Fnrnne f FT^II 


i c 7 ft | c a ft 7 




Yes LI NO >J N/A LJ 


DS5.3.1 


channel I 


1 S 2 ft 1 ^ 4 6 2 




Vac 1 i KJn 1 1 M/A 1 I 


DS5.3.2 


channel 2 


1 S 2 6 I S 4 6 2 


DS5.3:M 


IC» U INO IN/ A. U 


DS5.3.3 


channel 3 


1 S 2 6 1 S 4 6 2 


UOJ. J. IVl 


v*»c n Mn n m/a n 

ICS UJ INO U IN/ A. LJ 


DS5.3.4 


channel 4 


I S 2 ft IS 4 6 2 


UoJ. j. ivl 


vpc n Mr* n m/a n 

ICS ^ INO lN/A ^ 


DS5.3.5 


channel 5 


15 2 6 15 4 6 2 


DS5.3:M 


Ypc D Mn □ M/A f~l 


DS5.3.6 


channel 6 


15 2 6 1 S 4 6 2 


DS5.3:M 


Ypc Q Mn n M/A n 

ICS <«J 1NU U J IN/rV 


DS5.3.7 


channel 7 


15.2.6, 15.4.6.2 


DS5.3:M 


Yes 0 No □ N/A □ 


DS5.3.8 


channel 8 


15.2.6, 15.4.6.2 . 


DS5.3:M 


Yes □ No □ N/A Q 


DS5.3.9 


channel 9 


15.2.6, 15.4.6.2 


DS5.3:M 


Yes Q No □ N/A □ 


DS5.3.10 


channel 10 


15.2.6, 15.4.6.2 


DS5.3:M 


Yes Q No □ N/A □ 


DS5.3.U 


channel 1 1 


15.2.6, 15.4.6.2 


DS5.3:M 


Yes □ No □ N/A □ 


DS5.3.12 


channel 12 


15.2.6, 15.4.6.2 


DS5.3:M 


Yes □ No □ N/A □ 


DS5.3.13 


channel 13 


15.2.6, 15.4.6.2 


DS5.3:M 


Yes □ No □ N/A □ 


* DS5.4 


France 


15.2.6, 15.4.6.2 


DS5:0.1 


Yes Q No □ N/A □ 


DS5.4.1 


channel 10 


15.2.6, 15.4.6.2 


DS5.4:M 


Yes Q No □ N/A Q 
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A.4.6 Direct sequence PHY functions (continued) 



Item 


PHY feature 

I 


References 


Status 


Support 


DS5.4.2 


pnarinpl 1 1 




1 HQ^ A-\A 
Uo3.4.lVl 


Yes i-J NO U N/A LJ 


DS5.4.3 


channel 12 


1 ^ 2 6 1 5 4 6 2 


UJj.'-f.iVl 


ICS [NO -J iN/ A 1J 


DS5.4.4 


channel 13 


15 2 6 1 S 4 6 2 


DS5.4:M 


V*»c ("I NJr* O NJ/A i"l 


* DS5.5 


Spain 


M 2 6 1 5 4 6 2 


n<;s-n i 

UOJ.U. 1 


v*»c n Mo n m/a n 
ies u no -j N/A u 


DS5.5. 1 




1 ^ 2 (\ KilA? 




Yes LJ No U N/A LJ 


DS5.5.2 


rhannpl 1 1 


I J.Z.O, 1 J.*f .o.z 




Yes LJ No U N/A LI 


* DS5.6 


Japan (RCR) 


15.2.6, 15.4.6.2 


DS5:0.1 


Yes □ No □ N/A □ 


DS6 


Bits to symbol mapping 


15.4.6.4 






DS6.1 


1 Mbit/s 


15.4.6.4 


M 


Yes □ No □ 


DS6.2 


2 Mbit/s 


15.4.6.4 


M 


Yes □ No □ 


*DS7 


CCA functionality 


15.4.8.4 






DS7.1 


Energy Only (RSSI above threshold) 


15.4.8.4 


DS7:0.2 


Yes □ No □ 


DS7.2 


IEEE 802.1 1 DSSS correlation 


15.4.8.4 


DS7:0.2 


Yes □ No □ 


DS7.3 


Both methods 


15.4.8.4 


DS7:0.2 


Yes □ No □ 


DS7.4 


Hold CCA busy for packet duration of 
ti LuircLiiy received rL^r uui Ldrricr 
lost during reception of MPDU 


15.2.7 


M 


Yes □ No □ 


DS7.5 


Hold CCA busy for packet duration of 
a correctly received but out of 
specification PLCP 


15.2.7 


M 


Yes □ No □ 


DS8 


Transmit antenna selection 


15.4.5.5, 

1 . J.O 


O 


Yes □ No □ 


DS9 


JXCLC1VC alllCIiIla UiVCrMlY 


1 J.*T. J, J, 

15.4.5.6, 
15.4.5.7 


r\ 
\J 


Vcn- 1 i xi™ i i 
Yes U NO u 


*DS10 


. Antenna port(s) availability 


15.4.6.9 


O 


Yes □ No □ 


DS10.1 


50 CI impedance 


15.4.6.9 


DS10:M 


Yes □ No □ N/A □ 


•DSll 


Transmit power level support 


15.4.5.8, 
15.4.7.3 


O 


Yes □ No □ 


DSU.l 


If greater than 100 mW capability 


15.4.7.3 


DSll:M 


Yes □ No □ N/A □ 


*DS12 


Radio type (temperature range) 


15.4.6.10 






DS12.1 


Type 1 


15.4.6.10 


DS 12:0.3 


Yes □ No □ N/A □ 


DS12.2 


Type 2 


15.4.6.10 


DS 1 2:0.3 


Yes □ No Q N/A □ 


DS13 


Spurious emissions conformance 


15.4.6.5 


M 


Yes □ No □ 


DS14 


TX-RX turnaround time 


15.4.6.6 


M 


Yes □ No Q 


DS15 


RX-TX turnaround time 


15.4.6.7 


M 


Yes □ No □ 


DS16 


Slot time 


15.4.6.8 


M 


Yes □ No □ 


DS17 


ED reporting time 


15.4.6.8, 
15.4.8.4 


M 


Yes □ No □ 


DS18 


Minimum transmit power level 


15.4.7.2 


M 


Yes □ No □ 


DS19 


Transmit spectral mask conformance 


15.4.7.4 


M 


Yes □ No □ 


DS20 


Transmitted center frequency 
tolerance 


15.4.7.5 


M 


Yes □ No Q 
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A.4.6 Direct sequence PHY functions (continued) 



Item 


PHY feature 


References 


Status 


Support 


DS21 


Chip clock frequency tolerance 


15.4.7.6 


M 


Yes □ No □ 


DS22 


Transmit power on ramp 


15.4.7.7 


M 


Yes Q No □ 


DS23 


Transmit power down ramp 


15.4.7.7 


M 


Yes □ No □ 


DS24 


RF carrier suppression 


15.4.7.8 


M 


Yes □ No □ 


DS25 


Transmit modulation accuracy 


15.4.7.9 


M 


Yes Q No □ 


DS26 


Receiver minimum input level 
sensitivity 


15.4.8.1 


iM 


Yes Q No □ 


DS27 


Receiver maximum input level 


15.4.8.2 


M 


Yes □ No Q 


DS28 


Receiver adjacent channel rejection 


15.4.8.3 


M 


Yes □ No □ 


DS29 


MIB 


13.1, 15.3.2, 
Annex D 


M 


Yes □ No □ 


DS29.I 


dotl IPhyDSSSComplianceGroup, 
dot 1 1 PhyRegDomainsSupportGroup, 
and 

dot 1 1 PhyOperationComplianceGroup 


13.1, 15.3.2 


iM 


Yes □ No □ 



A.4.7 Infrared baseband PHY functions 



Item 


Feature 


References 


Status 


Support 


IR1 


[s the transmitted SYNC field length in the 
range of required number of PPM slots, with 
the absence of a pulse in the last slot of the 
field? 


16.2.4.1 


M 


Yes □ 


[R2 


Is the transmitted SYNC field entirely popu- 
lated by alternating presence and absence of 
pulses in consecutive PPM slots, with the 
absence of a pulse in the last slot of the field? 


16.2.4.1 


M 


Yes □ 


[R3 


Is the transmitted SFD field the binary 
sequence 1001, where 1 indicates a pulse in 
the PPM slot and 0 indicates no pulse in the 
PPM slot? 


16.2.4.2 


M 


Yes □ 


[R4 


Is the transmitted DR field pulse sequence 
equal to the correct value for the data rate 
provided by the TXVECTOR parameter 
PLCP BIT RATE, where 1 indicates a pulse 
in the PPM slot and 0 indicates no pulse in 
the PPM slot? 


16.2.4.3 


M 


YesQ 


IR5 


Is the transmitted DC LA field 32 PPM 
slots long with the specified sequence for 
1 Mbit/s, where'1 indicates a pulse in the 
PPM slot and 0 indicates no pulse in the 
PPM slot? 
1 Mbit/s: 

00000000 1 000000000000000 1 0000000 


16.2.4.4 


M 


Yes □ 


* IR5a 


Does the unit support 2 Mbit/s transmission? 


16.2.4.4 


O 


Yes □ No Q 
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A.4.7 Infrared baseband PHY functions (continued) 



Item 


Feature 


J References 


Status 


Support 


[R5b 


If the unit supports 2 Mbit/s transmission, 
is the transmitted DCLA field 32 PPM 
slots long with the specified sequence for 
2 Mbit/s, where 1 indicates a pulse in the 
PPM slot and 0 indicates no pulse in the 
PPM slot? 
2 Mbit/s: 

00100010001000100010001000100010 


| 16.2.4.4 

! 
j 


IR5a:M 


Yes □ No □ N/A □ 


IR6 


K the transmitted I FNGTH fipM thp rnrrprt 
PPM representation of the unsigned 16-bit 
binary integer, lsb transmitted first, equal to 
the correct value provided by the TX VEC- 
TOR parameter LENGTH? 




\A 

M 


Vac [ — i 

Yes u 


IR7 


Is the transmitted CRC field the correct PPM 
representation of the CRC value calculated 
as per reference subclause, transmitted lsb 
first? 


16.2.4.6 


M 


Yes □ 


IR8 


Is the transmitted PSDU field the correct 
PPM representation of the PSDU, transmit- 
ted lsb first? 


16.2.4.7 


M 


Yes □ 


IR9 


When the CCA is false does transmission 
begin based on PHYTXSTART.request? 


16-2.5.1 


M 


Yes □ 


IRtO 


Does the PHY issue a PHYTXSTART.con- 
firm after the transmission of the PLCP 
header? 


16.2.5.1 


M 


YesO 


IR11 


Does the PHY accept each octet of the 
PSDU in a PHYDATA.request and answer 
with a PHYDATA.confirm? 


16.2.5.1 


M 


YesO 


[R12 


Does the PHY cease transmission in 
response to a PHYTXEND. request and 
answer with a PHYTXEND. confirm? 


16.2.5.1 


M 


Yes □ 


IR13 


Does the PHY of a receiving STA send a 
PHYCCA.indicate during reception of the 
SYNC field? 


16.2.5.2 


M 


Yes □ 


IR14 


Does the PHY of a receiving STA properly 
receive a transmission that changes data rate 
according to the DR field? 


16.2.5.2 


M 


Yes □ 


[R15 


Does the PHY of a receiving STA properly 
reject an incorrect CRC? 


16.2.5.2 


M 


Yes □ 


IR16 


Does the PHY of a receiving STA properly 
reject a DR field other than those specified in 
reference subclause? 


16.2.5.2, 16.2.4.3 


M 


Yes □ 


[RI7 


Does the PHY of a receiving STA send 
PHYRXSTARTnndicate with correct RATE 
and LENGTH parameters after proper recep- 
tion of PLCP preamble and PLCP header? 


16.2.5.2 


M 


Yes □ 


IR18 


Does the PHY of a receiving STA forward 
receive octets in PHYDATA. indicate primi- 
tives? 


16.2.5.2 


M 


Yes □ 


IR19 


Does the PHY of a receiving STA send a 
PHYRXEND.indicate after the final octet 
indicated by the LENGTH field? 


16.2.5.2 


M 


Yes □ 
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A.4.7 Infrared baseband PHY functions (continued) 



Item 


Feature 


References 


Status 


Support 


IR20 


Does the PHY of a receiving STA send a 
PHYCC A. indicate with a state value of 
IDLE after the PHYRXEND.indicate? 


16.2.5.2 


M 


Yes □ 


[R21 


Does the PHY reset its CCA detection mech- 
anism upon receiving a PHYC- 
CARST.request, and respond with a 
PHYCCARST.indicate? 


16.2.5.3 


M 


Yes □ 


IR22 


When transmitting at 1 Mbit/s does the 
PHY transmit PPM symbols according to the 
16-PPM Basic Rate Mapping table, transmit- 
ting from left to right? 


16.3.2.1, 16.3.2.2 


M 


YesO 


[R23 


When transmitting at 2 Mbit/s does the 
PHY transmit PPM symbols according to the 
4-PPM Enhanced Rate Mapping table, trans- 
mitting from left to right? 


16.3.2.1, 16.3.2.2 


IR5a:M 


Yes □ 


IR24 


Does the PHY operate over a temperature 
range of 0 °C to 40 °C? 


16.3.2.4 


M 


Yes □ 


* [R25 


If the unit is conformant to emitter radiation 
mask 1, is the peak optical power of an emit- 
ted puise within the specification range aver- 
aged over the pulse width? 


16.3.3.1 


O.I 


Yes □ No □ N/A □ 


* IR26 


If the unit is conformant to emitter radiation 
mask 2, is the peak optical power of an emit- 
ted pulse within the specification range aver- 
aged over the pulse width? 


16.3.3.1 


0.1 


Yes □ No □ N/A □ 


IR27 


Does the transmitted pulse shape conform to 
the description of the reference subclause? 


16.3.3.2 


M 


Yes □ 


IR28 


Does the emitter radiation pattern as a func- 
tion of angle conform to the requirements of 
the reference subclause as applicable based 
on conformance to emitter radiation mask 1 ? 


16.3.3.3 


IR25:M 


Yes □ No □ N/A □ 


IR28a 


Does the emitter radiation pattern as a func- 
tion of angle conform to the requirements of 
the reference subclause as applicable based 
on conformance to emitter radiation mask 2? 


16.3.3.3 


IR26:M 


Yes □ No □ N/A □ 


IR29 


Is the peak emitter optical output as a func- 
tion of wavelength in the range specified? 


16.3.3.4 


M 


Yes □ 


IR30 


Does the spectrum of the transmit signal 
amplitude as a voltage or current meet the 
requirements of the reference subclause? 


16.3.3.5 


M 


Yes □ 


IR31 


Does the receiver sensitivity meet the 
requirements of the reference subclause 
for receive signals of both 1 Mbit/s and 
2 Mbit/s? ' 


16.3.4.1 


M 


Yes □ 


IR32 


Does the receiver exhibit a dynamic range as 
specified in reference subclause? 


16.3.4.2 


M 


Yes Q 


IR33 


Does the receiver fietd-of-view conform to 
the requirements of the reference subclause? 


16.3.4.3 


M 


Yes □ 


IR34 


When it is known that the conditions are 
such that the Carrier Detect Signal and the 
Energy Detect Signal are false is the CCA 
asserted IDLE? 


16.3.5.1 


M 


YesQ 
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A.4.7 Infrared baseband PHY functions (continued) 



Item 


Feature 


References 


Status 


Support 


IR35 


When the conditions are such that Energy 
Detect is true for greater than the time 
defined in reference subclause, does CCA 
become IDLE? 


16.3.5.1 


M 


Yes □ 


IR36 


When conditions are such that either Carrier 
Detect or fenergy Detect go true, does CCA 
go BUSY? 


16.3.5.1 


M 


Yes □ 


IR37 


Are these compliance groups implemented? 
dot [ 1 PhylRComplianceGroup, 
dott IPhyRegDomainsSupportGroup, and 
dot 1 IPhyOperationComplianceGroup 


16.4 


M 


Yes □ 
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(informative) 

Hopping sequences 

The following tables pertain to the hopping sequences for North America and ETSI. 
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Table B.1— Hopping sequenc set 1 



index 


0 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


t 


2 


5 


8 


1 1 


14 


17 


20 


23 


26 


29 


32 


35 


38 


2 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


3 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


4 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


5 


45 ! 48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


6 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


7 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


8 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


2! 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


10 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


tl 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


12 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


13 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


14 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


15 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


16 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


17 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


18 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


19 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


20 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


21 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


22 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


23 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


24 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


25 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


26 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


27 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


28 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


29 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


30 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


31 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


32 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


33 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


34 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


35 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


36 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


37 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


38 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


39 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 
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Table B.1— Hopping sequence set 1 (continued) 



index 


0 


3 


6 


9 


12 


15 


18 


21 


24 


27 | 30 


33 


36 


40 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 j 57 


60 


63 


41 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 | 46 


49 


52 


42 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


43 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


44 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


45 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


46 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


47 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


48 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


49 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


50 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


51 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


52 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


53 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


54 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


55 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


56 


35 


38 


41 


44 


47 ' 


50 


53 


56 


59 


62 


65 


68 


71 


57 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


58 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


59 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


60 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


61 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


62 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


63 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


64 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


65 


8 


11 


14 


17 


20 


23 


26 


29 


32 


.35 


38 


41 


44 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


67 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


68 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


69 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


70 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


71 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


72 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


73 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


74 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


75 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


76 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


77 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


78 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


79 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 
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Table B.1 — Hopping sequence set 1 (continued) 



index 


! 39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


1 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


2 


64 


67 


70 


73 


76 


79 


3 


6 


0 


12 


!5 


18 


2! 


3 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


4 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


5 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


6 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


7 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


8 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


9 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


10 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


11 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


12 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


13 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


5t 


54 


57 


14 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


15 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


16 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


17 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


18 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


19 


72 


75 


78 


2 


5 


8 


It 


14 


17 


20 


23 


26 


29 


20 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


21 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


22 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


23 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


24 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


25 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


26 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


27 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


28 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


29 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


30 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


31 


75 


78 


2 


5 


8 


It 


14 


17 


20 


23 


26 


29 


32 


32 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


33 


48 


51 


54 


57 


60 


.63 


66 


69 


72 


75 


78 


2 


5 


34 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


35 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


36 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


37 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


38 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


39 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 
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Table B.1 — Hopping sequence set 1 (continued) 



index 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 | 75 


40 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 | 23 


41 


55 


58 


61 


| 64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


42 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


43 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


44 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


45 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


46 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


48 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


49 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


50 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


51 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


52 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


53 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


54 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


55 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


56 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


57 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


58 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


59 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


60 


4 


7 


to 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


61 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


62 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


63 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


64 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


65 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


66 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


67 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


68 


2 


5 


8 


tl 


14 


17 


20 


23 


26 


29 


32 


35 


38 


69 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


70 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


71 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


72 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


73 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


74 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


75 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


76 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


77 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


78 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


79 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 
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Table B.2 — Hopping sequence s t 2 



index 


1 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


1 


3 


6 


9 | 12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


2 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


3 


65 


68 


71 


" 74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


4 


li 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


5 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


7 


74 


77 


80 


4 


7 


to 


13 


16 


19 


22 


25 


28 


31 


8 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


9 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


L0 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


11 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


12 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


13 


62 


65 


68 


71 


74 


77 


80 


4 


7 


to 


13 


16 


19 


14 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


15 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


16 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


17 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


18 


80 


4 


7 


to 


13 


16 


19 


22 


25 


28 


31 


34 


37 


19 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


20 


5 


8 


It 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


21 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


22 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


23 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


24 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


25 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


tl 


14 


26 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


27 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


28 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


29 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


30 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


31 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


32 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


33 


10 


13 


16 


19 


22 


25 


28 


3! 


34 


37 


40 


43 


46 


34 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


35 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


36 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


37 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


38 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


39 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 
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48 
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Table B.2— Hopping sequence s 1 2 (continued) 



index 


1 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


41 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


42 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


1 1 


14 


17 


43 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


44 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


45 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


46 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


47 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


48 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


49 


2 


5 


8 


It 


14 


17 


20 


23 


26 


29 


32 


35 


38 


50 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


51 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


52 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


53 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


54 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


55 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


56 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


57 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


58 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


59 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


60 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


61 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


62 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


63 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


64 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


65 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


66 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


67 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


68 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


69 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


70 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


71 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


72 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


73 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


74 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


75 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


76 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


77 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


78 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


79 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 
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Table B.2 — Hopping sequence s 1 2 (continued) 



index 


40 


43 


46 


49 | 52 


55 


58 1 61 


64 


67 


70 


73 


76 


1 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


3 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


4 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


5 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


6 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


7 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


8 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


9 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


10 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


11 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


12 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


13 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


14 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


15 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


16 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


17 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


18 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


19 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


20 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


21 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


22 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


23 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


24 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


25 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


26 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


27 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


28 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


29 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


30 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


31 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


32 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


33 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


34 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


36 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


37 


23 


26 


29 


32 


35 


38 


41 


44 
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50 


53 


56 


59 


38 


69 
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75 
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2 
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Table B.2— Hopping sequence set 2 (continued) 



index 


40 


43 


46 


49 


52 | 55 


58 1 61 


64 


67 | 70 


73 


76 


40 


67 


70 


73 


76 


79 


3 


6 1 9 

i 


12 


15 


18 


21 


24 


4! 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


42 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


43 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


44 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


45 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


46 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


47 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


48 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


49 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


50 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


51 


62 


65 


68 


71 


74 


77 


80 


4 


7 


to 


13 


16 


19 


52 


36 


39 


42 


45 


48 


51 


- 54 


57 


60 


63 


66 


69 | 72 


53 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


54 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


55 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


56 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


57 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64. 


58 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


59 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55. 


60 


5 


8 


It 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


61 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


62 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


63 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


64 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


to 


13 


16 


65 


48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5, 


66 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


67 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


68 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


69 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


70 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


71 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


72 


77 


80 


4 


7 


1° 


13 


16 


19 


22 


25 


28 


31 


34 


73 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


74 


66 


69 


72 


75 


78 


2 


5 


8 


It 


14 


17 


20 


23 


75 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


76 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


77 


80 


4 


7 


to 


13 


16 


19 


22 


25 


28 


31 


34 


37 


78 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


79 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 
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Table B.3 — Hopping s quence set 3 



index 


2 


5 


8 


11 


14 | 17 


20 


23 | 26 


29 1 32 


35 


38 


1 


. 4 


7 


10 


13 


16 


19 


22 


25 | 28 


31 


34 


37 


40 


2 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


3 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


4 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


5 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


6 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


7 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


8 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


5 


8 


9 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


10 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


11 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


12 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


13 


63 


66 


69 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


14 


26 


29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


15 


56 


59 


62 


65 


68 


71 


74 


77 


80 


4 


7 


to 


13 


16 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


17 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


18 


2 


5 


8 


It 


14 


17 


20 


23 


26 


29 


32 


35 


38 


19 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


20 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


21 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


22 


15 


18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


23 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


24 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


25 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


26 


73 


76 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


27 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


28 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


29 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


77 


30 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


50 


31 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


68 


71 


74 


32 


70 


73 


76 


79 


3 


6 


9 


12 


15. 


18 


21 


24 


27 


33 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


47 


34 


72 


75 


78 


2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


35 


79 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


36 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


41 


44 


37 


64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


2t 


38 


31 


34 


37 


40 


43 


46 


49 


52 


55 


58 


61 


64 


67 


39 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


52 
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Table B. 3— Hopping sequenc set 3 (continued) 



index | 2 


5 


8 


11 


14 


17 


20 


23 


26 


29 


32 


35 


38 


40 | 29 


32 


35 


38 


41 


44 


47 


50 


53 


56 


59 


62 


65 


41 | 18 


21 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


42 


61 | 64 


67 


70 


73 


76 


79 


3 


6 


9 


12 


15 


18 


43 


45 48 


51 


54 


57 


60 


63 


66 


69 


72 


75 


78 


2 


44 


78 


2 


5 


8 


II 


14 


17 


20 


23 


26 


29 


32 


35 


45 


36 


39 


42 


45 


48 


51 


54 


57 


60 


63 


66 


69 


72 


46 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


47 


13 


16 


19 


22 


25 


28 


31 


34 


37 


40 


43 


46 


49 


48 


62 


65 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


49 


3 


6 


9 


12 


15 


18 


21 


24 


27 


30 


33 


36 


39 


50 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 


79 


3 


6 


51 


24 


27 


30 


33 


36 


39 


42 


45 


48 


51 


54 


57 


60 


52 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


28 


31 


34 


53 


68 


71 


74 


77 


80 


4 


7 


10 


13 


16 


19 


22 


25 


54 


43 


46 


49 


52 


55 


58 


61 


64 


67 


70 


73 


76 
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Annex C 

(normative) 

Formal description of MAC operation 

This annex contains formal descriptions of the behavior of MAC station (STA) and access point (AP) enti- 
ties. These descriptions also describe the frame formats and the generation and interpretation of information 
encoded in MAC frames, in the parameters of service primitives supported by the MAC, and in MIB 
attributes used or generated by the MAC. The MAC is described using the 1992 version of the ITU Specifi- 
cation and Description Language (SDL-92). SDL-92 is defined in ITU-T Recommendation Z.100 (03/93). 
An update to Z. 100 was approved in 1996 (SDL-96), but none of the SDL facilities used in this annex were 
modified. An introduction to the MAC formal description is provided in Clause C.l . Definitions of the data 
types and operators used by the MAC state machines are provided in Clause C.2. An SDL system describing 
MAC operation at an IEEE 802. 1 1 station is contained in Clause C.3. Finally, a subset of an SDL system 
describing the aspects of MAC operation at an IEEE 802.1 1 AP that differ from operation at a non-AP sta- 
tion is provided in Clause C.4. 

In Annex D, the MAC and PHY management information bases are described in Abstract Syntax Notation 
One (ASN.l), defined in ISO/IEC 8824: 1990 and ISO/IEC 8825: 1990. ITU-T Recommendation Z. 105 (03/ 
95) defines the use of SDL in conjunction with ASN.l, allowing system behavior to be defined using SDL 
and data types to be defined using ASN.l. Incomplete tool support precluded the use of ITU-T Recommen- 
dation Z.105 in this annex. However, within the limits of ITU-T Recommendation Z.100 (referred to subse- 
quently as Z.100), the data types in Clause C.2 are defined in a similar manner to ITU-T Recommendation 
Z.105 (referred to subsequently as Z.105). Annex E contains a listing of available documentation. 

NOTES 

1 — The SDL definitions in this annex should be usable with any SDL tool that supports the 1993 version or 1996 update 
of ITU-T Recommendation Z.100. Software for generating, analyzing, verifying, and simulating SDL system descrip- 
tions is available from several sources. 

2— The SDL code in this annex was generated using SDT/PC version 3.02; from Teielogic AB, Malmo, Sweden (+46- 
40-174700; internet: telelogic.se); USA office in Princeton, NJ (+1-609-520-1935; internet: telelogic.com). Teielogic 
offers SDT for several workstation platforms in addition to SDT/PC. 

3 — The use of Telelogic's product to prepare this annex does not constitute an endorsement of SDT by the IEEE LAN 
MAN Standards Committee or by the IEEE. 

4— The diagrams on the next two pages show most of the symbols' of SDL graphical syntax (SDL-GR) used in the MAC 
formal description. The symbols in these diagrams have labels and comments that explain their meanings. These dia- 
grams are intended to serve as a legend for the SDL-GR symbols that comprise most of the process interaction and state 
transition diagrams. These diagrams are neither a complete SDL system, nor a complete presentation of SDL-GR sym- 
bology. Also, this state machine fragment exists to illustrate the SDL graphical syntax, and does not describe any useful 
behavior. 
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Block lnteraction_Page_Legend 



la(l) 



Block.Z 



iThis is a block reference symbol. 
- J Blocks are ihe fundamental unit of lexical 
, scope and structural hierarchy. Each block 
■contains other blocks and/or processes, 
'procedures, and data declarations. 



After the process name 
is the number of process 
instances at startup and . 
the maximum number of 
instances. For processes! 
created dynamically, the 
dashed arrow connects 
the parent process to 
the offspring process. 




i This is a process reference symbol. 
- J Processes specify dynamic behavior using 
,extended finite state machines. Processes 
i operate concurrently, communicating by means 
jof signals and remote variables (import/export). 



Uni direct ional_ 
Signal Route 



Process_B (O.max) 



Signals] 



Bidirectional 
Signal Route ~ 



Signal I. 
Signal 2 



Signal3, 
SignaM 



Process.C (l : 1 ) 



Signal Route_ 
OutOfBlock 



PT 



Signa!2. 
Signal 6 



The connection point name 
where a signal route hits the 
block boundary identifies the 
continuation of that signal 
route in the enclosing block. 



[Signal3] 



Procedure_Name 



i This is a procedure reference symbol. 
-jA procedure is defined and called in the process where this 
i symbol appears. If declared "remote" the procedure may be 
'imported for calling from other processes. A value- returning 
(procedure, callable in assignment statements, is defined using 
(the "returns" keyword in the formal parameter list. 



operator 

Operator_Name 



iThis is an operator reference symbol. 
-J Operators for custom sorts may be defined axiomatical ly or 
,algorithmically. An algorithmic operator is similar to a 
i value-returning procedure, except the operator does not use 
| states nor outputs, and does not modify its source operands. 
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Process State_Machine_Legend 



la(L) 



/* This is a text symbol, used to hold K 
data type (sort) definitions, declarations, 
signal lists, and other SDL statements that 
have no graphical representation. */ 



CD- 



^ State. I \- 



i Process Start symbol 
J(One per process. 
(Contains no text.) 



i State symbol, arrowhead 
J indicates transition(s) 
| entering the state. 



* in a state symboli 
means all states 
except those listed 



gnal^z 
✓hen in 
any state' 



- in a state symboli 
refers to the state \ 
from which the i 
transition began. J 



signal_A 



i Input symbol with wedge on left 
- .[side used for signals from LLC. 
iS.ME, self, and others logically 
[above or parallel to this process. 



(state_x. 
state_y) 



actions in 
response to 
signal_z* 







\ error_sign«i 
Vail states 
/ except x.y' 






'actions to 
recover from 
error' 







J ^ state_N j 



^ State_2 J- 



i The transition taken when multiple 
-■(inputs follow a state is determined 
iby the first of the named signals to 
j reach the head of the input queue. 



signal_A. 
signal_B 



gnaLC 
gnal_D. 



signal_E 
'text extension 
symbol, holds 
overflow text' 



signal_G - - J si< 



nput symbol with wedge on right 
>ide used for signals from PHy & 
others logically below this process. 



'task symbol 
for algorithmic 
process steps' 



<:onditional\ 
expression 7~ ' 



iThis transition is 
.(able to begin only 
iwhen its Enabling 
'Condition is true. 



^ ^out_sig_l 




i Output symbol with point to left 
- -[side used for signals to LLC. 
iSME. self, and others logically 
[above or parallel to this process. 

iCreate Request symbol used for 
■j dynamic creation of an instance 
j of the specified process type. 




Output symbol with point to right 
d for simials to PHY & 



side use 
others logically 



jelow this process. 



'call' 
macro 
(parms) 



State_2 



) A signal at head of the process 
■[input queue that is not named 
;in any of the suite's input 
•symbols is discarded unless 
•named in a Save symbol attached 
| to the state. * Save refers 
ito all remaining signal names. 



signaI_F 



i A Priority Input symbol enables its 
J transition if the named signal is 
[anywhere in the process input queue. 



t 



priority_ 
signal 



other_signal 



^ - j / NexcState j 
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C.1 Introduction to the MAC formal description 

This formal description defines the behavior of IEEE 802.1 1 MAC entities. The MAC protocol functional 
decomposition used herein facilitates explicit description of the reference points and durations of the various 
timed intervals; the bases for generation and/or validation of header fields, service parameters, and MIB 
attributes; and the interpretation of each value in cases where enumerated data types are used in service 
parameters. 

C.1.1 Fundamental assumptions 

The MAC protocol is described as an SDL system, which is a set of extended finite state machines. Each 
state machine is a set of independent processes, all of which operate concurrently. All variable data-holding 
entities and procedures exist solely within the context of a single process. In SDL all interprocess communi- 
cation is done with signals (there are no global variables). Signals may be sent and received explicitly, using 
SDL's output and input symbols, or implicitly, using SDL's export/import mechanism (only if the variables 
or procedures are declared "remote"). By default, signals incur delays when traversing channels between 
blocks; however, only nondelaying channels and signal routes are used in the MAC state machines, and all 
remote variables and procedures are declared with the "node lay" property. 

State transitions, procedure calls, and tasks (assignment statements and other algorithmic processing steps) 
are assumed to require zero time. This permits the time intervals that are part of the normative MAC behav- 
ior to be defined explicitly, using SDL timers. One unit of system time (a 1.0 change in the value of "now") 
is assumed to represent one microsecond of real time. Usee (microsecond) and TU (time unit) data types are 
defined, with operators to convert Usee and TU values to SDL time or duration when necessary. 

The SDL system boundary encloses the MAC entities. The LLC, SME, PHY, and distribution system are 
part of the environment. SDL generally assumes that entities in the environment operate as specified; how- 
ever, the MAC state machines that communicate with the various SAPs attempt to validate inputs from the 
environment, and to handle cases where a pair of communicating entities, one within the system and the 
other outside the system boundary, have different local views of the medium, station, or service state. All sta- 
tions in an IEEE 802.11 service set are assumed to exhibit the behaviors described herein. Nevertheless, 
because of the open nature of the wireless medium, the MAC state machines check for error cases that can 
arise only when an entity on the wireless medium is transmitting IEEE 802. 1 1 PDUs, but is not obeying the 
communication protocols specified by this standard. 

C.1.2 Notation conventions 

When practical, names used in the clauses of this standard are spelled identically in this annex. The principal 
exceptions are those names that conflict with one of SDL's reserved words (such as power management 
mode "active," which is renamed "sta_active" in SDL). To help fit the SDL text into the graphic symbols, 
acronyms with multiple, sequential capital letters are written with only the first letter capitalized (e.g., 
"MSDU" is written "Msdu" and "MLMEJoin. request" is written "Mime Join. request"). 

SDL reserved words and the names of variables and synonyms (named constants) begin with lowercase let- 
ters. The names of sorts (data types), signals, signal routes, channels, blocks, and processes begin with 
uppercase letters. The names of certain groups of variables and/or synonyms begin with a particular lower- 
case letter, followed by the remainder of the name, beginning with an uppercase letter. These groups are 

"aNameOfAttribute" PHY operational parameters. 

"cNameOfCapability" Capability bits, also used for internal values exported as MIB counters. 

"dNameOfDuration" Duration (relative time) values, declared as Usee, TU, or Duration, 

"dot 1 1 NameOfAttribute" MIB attributes. 
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"eNameOfElement" Element ID values. 

"mNameOfVariable" Remote variables used for intra-MAC communication, but not part of the MIB. 

Most of these variables are exported from the MLME block. 
"sNameOfStaticValue" Synonyms for static data values used within the MAC. 

"tNarneOfTime" Time (absolute time) values, declared as Usee, TU, or Time. The names of timers 

begin with "T" 



C.1.3 Modeling techniques 

State machines are grouped according to defined function sets that are visible, directly or indirectly, at an 
exposed interface. The emphasis in the organization of the state machines is explicitly to show initiation of 
and response to events at the exposed interfaces, and time-related actions, including those dependent on the 
absence of external events (e.g., response timeouts) and intervals measured in derived units (e.g., backoff 
"time" in units of slots during which the wireless medium is idle). The operations associated with the various 
state transitions emphasize communication functions. Most of the details regarding insertion, extraction, and 
encoding of information in fields of the PDUs is encapsulated with the definitions of those fields. This 
approach, which relies heavily on SDL's abstract data type and inheritance mechanisms, permits the behav- 
ior of the data-holding entities to be precisely defined, without obscuring process flow by adding in-line 
complexity to the individual state transitions. 

The modeling of PDUs and SDUs requires sorts such as octet strings, and operators such as bitwise boolean 
functions, which are not predefined in SDL. These sons and operators are defined in Package macsorts, 
which appears in Clause C.2. 

Protocol and service data unit sorts are based on the Bit sort. Bit is a subtype of SDL's predefined Boolean 
sort. As a result, Bit literals "0" and "1" are alternative names for "false" and "true," and have no numeric 
significance. To use "0" or "1" as integer values requires a conversion operation. Items of the Bitstring sort 
are 0-origin, variable- length strings of Bits. With Bitstring operands, operators "and," "or," "xor," and "not" 
operate bitwise, with the length of the result equal to the length of the longest (or only) source string. The 
Octet sort is a subtype of Bitstring that adds conversion operators to and from Integer. Each item of the 
Octet sort has length=8 {by usage convention in Z. 100, enforced in Z. 105}. Items of the Octetstring sort are 
0-origin, variable-length strings of Octets. The Frame sort is a subtype of Octetstring that adds operators to 
extract and to modify all MAC header fields and most other MAC frame fields and elements. Most MAC 
fields and elements that contain named values with specific value assignments or enumerations are defined 
as subtypes of Frame, Octetstring, or Bitstring with the names added as literals or synonyms, so that the state 
machines can refer to the names without introducing ambiguity about the value encodings. 

Where communication at a SAP or between processes is strictly first in first out (FIFO), the (implicit) input 
queue of the SDL processes is used. When more sophisticated queue management is needed, a queue whose 
entries are instances of one, specified sort is created using the Queue generator. Entries on Queue sorts may 
be added and removed at either the tail or the head, and the number of queue entries may be determined. The 
contents of a Queue may also be searched to locate entries with particular parameter values. 

Clause C.2 contains an SDL-92 Package (a named collection of SDL definitions that can be included by ref- 
erence into an SDL System specification), which is a formal description of the formats and data encodings 
used in IEEE 802.1 1 SDUs, PDUs, and the parameters of the service primitives used at each of the SAPs 
supported by the IEEE 802.1 1 MAC. This package also contains definitions for some data structures and 
operators used internally by one or more of the MAC state machines. 

The behaviors of many intra-MAC operators are part of the normative description of the MAC protocol 
because results of the specified operations are visible, directly or indirectly, at exposed interfaces. For exam- 
ple, custom operators are used to define the generation of the CRC-32 value used in the FCS field (operator 
crc32, page 301), the calculation of frame transmission time used as part of the value in the Duration/ID field 
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in certain types of frames (operator calcDur, page 3 16), the comparison of the values of particular fields of a 
received MAC header with cached data values as part of the procedure for detecting duplicate frames (oper- 
ator searchTupleCache, page 289), and numerous other aspects of frame formats and information encoding. 
On the other hand, data structures used solely for intra-MAC storage or for transferring of information 
between different state machines of a single station or access point, are only normative to the extent that they 
define items of internal state and the temporal sequence necessary for proper operation of the MAC protocol. 
The specific structures and encodings used for internal data storage and communication functions in this for- 
mal description do not constrain MAC implementations, provided those implementations exhibit the speci- 
fied behaviors at the defined SAPs and, in conjunction with an appropriate PHY, on the wireless medium. 

C.2 Data type and operator definitions for the MAC state machines 

This clause is in SDL/PR (phrase notation), with the exception of procedural operators, which are defined in 
SDL/GR (graphic notation). Package macsorts contains the definitions of the sorts (data types with associ- 
ated operators and literals) and synonyms (named constants) used by the MAC state machines. Package 
macrnib defines data types for attributes in the MAC MIB, and portions of the PHY MIB, accessed by the 
MAC state machines. Package macrnib exists solely to satisfy SDL's strong type checking in the absence of 
an SDL tool that fully supports Z.105 (the combined use of SDL with ASN.l). 
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Package macsorts 



3101_d\MacEnum(31) 



/* PACKAGE MACSORTS 7 
/• This package contains definitions of the custom sorts (data types), operators! 
literals, and synonyms (named constants) used by the MAC state machines. 7 



/ K 

Enumerated types used within the MAC state machines 

newtype ChangeType /* type of change due at the next boundary 7 
literals dwell, r dwell (only with FH PHY) 7 

mocp; r medium occupancy (only with PCF) 7 
endnewtype ChangeType; 

newtype Imed /* priority for queuing MMPDUs, relative to MSDUs */ 
literals head, /* place MMPDU at head of transmit queue 7 
norm; /* place MMPDU at tail of transmit queue 7 
endnewtype Imed; 

newtype NavSrc /* source of duration in SetNav & ClearNav signals 7 
literals rts, /* RTS frame 7 

cfpBss, cfendBss, P start/end of CFP in own BSS 7 

cfpOther, cfendOther, /* start/end of CFP in other BSS 7 

cswitch, /* channel switch 7 

misc, /* durld from other frame types 7 

nosrc; /* non- reception events */ 
endnewtype NavSrc; 

newtype PsMode /* power save mode of a station (PsResponse signal) 7 

literals sta_active, power_save, unknown; endnewtype PsMode; 
newtype PsState /* power save state of this station 7 

literals awake, doze; endnewtype PsState; 
newtype StateErr /* requests disasoc or deauth (Mmlndicate signal) 7 

literals noerr, class2, class3; endnewtype StateErr; 
newtype StationState /* asoc/auth state of sta (SsResponse signal) 7 

literals not_auth, auth_open, auth_key, asoc, dis_asoc; 
endnewtype StationState; 

newtype TxResult /* transmission attempt status (PduConfirm signal) 7 
literals successful, partial, retrytimit, txLifetime, 
atimAck, atimNak; endnewtype TxResult; 



Enumerated types used in PHY service primitives 



r 7 



newtype CcaStatus r <state> parameter of PhyCca. indication 7 

literals busy, idle; endnewtype CcaStatus; 
newtype PhyRxStat r <rxerror> parameter of PhyRxEnd. indication 7 

literals no_error, fmt_violation, carrier_lost, unsupt_rate; 
endnewtype PhyRxStat; 



K 

Placeholders for Mlme/Plme Get/Set Parameter Values^ 



/* MibAtrib (placeholder in MlmeGet/Set definitions) 7 
syntype MibAtrib = Charstring endsyntype MibAtrib; 

/* MibValue (placeholder in MlmeGet/Set definitions) 7 
syntype MibValue = Integer endsyntype MibValue; 



'7 
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Package macsorts 



3102_d\LmeEnum(31) 



Enumerated types used in Mac and Mime service primitives 

newtype AuthType /* <authentication type> parm in Mime primitives */ 

inherits Octets t ring operators all; 

adding literals open_system, shared_key; 

axioms open_system == mkOS(0, 2); shared_key == mkOS(1 , 2); 
endnewtype AuthType; 

newtype AuthTypeSet powerset( AuthType); endnewtype AuthTypeSet; 
newtype BssType /* <BSS type> parameter & BSS description element */ 

literals infrastructure, independent, any_bss; endnewtype BssType; 
newtype BssTypeSet powerset( BssType); endnewtype BssTypeSet; 
newtype CfPriority I* <priority> parameter of various requests 7 

literals contention, contentionFree; endnewtype CfPriority; 
newtype MibStatus T <status> parm of Mlme/Plme Get/Set.confirm */ 

literals success, invalid, write_only, read_only; 
endnewtype MibStatus; 

newtype MlmeStatus /* <status> parm of Mime operation confirm */ 
literals success, invalid, timeout, refused, 

tomany_req, atready_bss; endnewtype MlmeStatus; 
newtype PwrSave f* <power save mode> parameter of MlmePowerMgt */ 

literals sta_active, power_save; endnewtype PwrSave; 
newtype Routing r < routing info> parameter for MAC data service */ 

literals null_rt; endnewtype Routing; 
newtype RxStatus T < reception status> parm of MaUnitdata indication */ 

literals rx_success, rx_failure; endnewtype RxStatus; 
newtype ScanType /* <scan type> parameter of MlmeScan. request */ 
literals active_scan, passive_scan; endnewtype ScanType; 
newtype ServiceClass I* <service class> parameter for MaUnitdata */ 
literals reorderable, stricttyOrdered; endnewtype ServiceClass; 
newtype TxStatus f* transmission status> parm of MaUnitdataStatus V 
literals successful, retryLimit, btLifetime, noBss, 
excessiveDataLength, nonNullSourceRouting, 
unsupported Priority, unavailablePriority, 
unsupportedServiceClass, unavaitableServiceClass, 
unavailableKeyMapping; endnewtype TxStatus; 
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Package macsorts 31 03_e\lntraMac(31 ) 

> \ I/ K 

j * ] intra-MAC remote variables (names of form mXYZ) 

I J ***• * / 

remote mActingAsAp Boolean nodelay; r =true if STA started BSS 7 
remote mAld Asocld nodelay; /* AID assigned to STA by AP 7 
remote mAssoc Boolean nodelay; r =true if STA associated w/BSS 7 
remote mAtimW Boolean nodelay; r =true if ATIM window in prog 7 
remote mBkIP Boolean nodelay; /* =true if backoff in prog 7 
remote mBrates Ratestring nodelay; /* basic rate set for this sta 7 
remote mBsstd MacAddr nodelay; /* identifier of cun-ent (l)BSS 7 
remote mCap Octetstring nodelay; /* capability info from MlmeJoin 7 
remote mCfp Boolean nodelay; /* =true if CF period in progress 7 
remote mDisable Boolean nodelay; I* =true if not in any BSS; then 7 
/* TX only sends probe_req; RX only accepts beacon, probe_rsp 7 
remote mDtimCount Integer nodelay; /* =0 at Tbtt of Beacon with DTIM 7 
remote mFxIP Boolean nodelay; /* =true during frame exchange seq 7 
remote mlbss Boolean nodelay; r =true if STA is member of IBSS 7 
remote mListenlnt Integer nodelay; /* beacons between wake up @TBTT 7 
remote mNavEnd Time nodelay; /* NAV end Time, <=now when idle 7 
remote mNextBdry Time nodelay; /* next boundary Time; =0 if none 7 
remote mNextTbtt Time nodelay; /* Time next beacon due to occur 7 
remote mPcAvail Boolean nodelay; /* =true if point coord in BSS 7 
remote mPcDIvr Boolean nodelay; T =true if CF delivery only 7 
remote mPcPoll Boolean nodelay; /* =true if CF delivery & polling 7 
remote mPdly Usee nodelay; /* probe delay from start or join 7 
remote mPss PsState nodelay; /* power save state of STA 7 
remote mReceiveDTIMs Boolean nodelay; r =true if DTIMs received 7 
remote mRxA Boolean nodelay; /* =true if RX indicated by PHY 7 
remote mSsId Octetstring nodelay; r name of the current (l)BSS 7 
remote procedure TSF nodelay; /* read & update 64-bit TSF timer 7 
fpar Integer, Boolean; returns Integer; 
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Package macsorts 



3104_d\StaticData(31) 



Named static data values (names of form sXYZ) 



synonym sMaxMsduLng Integer = 2304; r max octets in an MSDU 7 
synonym sMacHdrLng Integer = 24; I* octets in data header, no WEP */ 
synonym sWepHdrLng Integer = 28; /* octets in data header with WEP 7 
synonym sWepAddLng Integer = 8; I* octets added for WEP 7 
synonym sWdsAddLng Integer = 6; I* octets added for WDS (addr4) 7 
synonym sCrcLng Integer = 4; V octets for crc32 (FCS, ICV) 7 
synonym sMaxMpduLng Integer = /* max octets in an MPDU 7 

(sMaxMsduLng + sMacHdrLng + sWdsAddLng + sWepAddLng + sCrcLng); 
syntype FramelndexRange = Integer /* index range for octets in MPDU 7 

constants 0 : sMaxMpduLng endsyntype FramelndexRange; 
synonym sTsOctet Integer = 24; /* first octet of Timestamp field */ 
synonym sMinFragLng Integer = 256; /* min value for aMpduMaxLength */ 
synonym sMaxFragNum Integer = V maximum fragment number 7 

(sMaxMsduLng / (sMinFragLng - sMacHdrLng - sCrcLng)); 
synonym sAckCtsLng Integer =112; /* bits in ACK and CTS frames 7 



* Station configuration flags (static, supplementary to MIB) 
* * * — v 

synonym s Version Integer = 0; /* supported Protocol Version 7 
synonym sCanBeAp Boolean = false; /* =true if STA can operate as AP 7 
synonym sCanBePc Boolean = false; /* =true if AP can be Point Coord 7 
synonym sCfPollabie Boolean =true; /* =true if responds to CF-polls 7 
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Package macsorts 3105_d\Usec_TU(31) 



>\ |/ *** **** K 
1 ) * Discrete microsecond and Time Unit sorts 

..J **** * ***** — ***** * / 

/* SDL does not define the relationship between its concept 7 
/" of Time and physical time in the system being described. */ 
/* An abstraction is needed to establish this relationship, 7 
/* because Time in SDL uses the semantics of Real, whereas 7 
/* time in the MAC protocol is discrete, with the semantics 7 
/* of Natural and a step size (resolution) of 1 micosecond. 7 
/* Most MAC times are defined using the subtypes of Integer 7 
/* Usee and TU. These have operators for explicit conversion 7 
/* to SDL Time (tUsec, tTU), SDL Duration (dUsec, dTU), and 7 
r from SDL Time (uTime, tuTime) as needed to comply with SDL's 7 
r strong type checking. Where the MAC state machines need to 7 
/* access the contents of the TSF timer, SDL's 'now' (current */ 
/* time) is used. This yields readable time-dependent code, 7 
/* but the value of 'now 1 cannot be modified by an SDL program, 7 
r so adopting the TSF time from timestamps in received Beacons 7 
r or Probe Responses is shown as an informal task symbol. 7 
/* Microsecond sort - also has operators tmin and tmax 7 
new type Usee inherits Integer operators all; 
adding operators 
dUsec : Usee -> Duration; 
tUsec : Usee -> Time; 
uTime : Time -> Usee; 
tmax : Usee, Usee -> Usee; 
tmin : Usee, Usee -> Usee; 
axioms for all u, w in Usec( 

u >= w ==> tmax(u, w) == u; u < w ==> tmax(u, w) == w; 
u >= w ==> tmin(u, w) == w; u < w ==> tmin(u, w) == u; 
for all t in Time( for all r in Real( 

r = float(u) ==> tUsec(u) == Time!(Duration!(r)); 
t = Time!(Duration!(r)) and u = fix(r) ==> u == uTime(t);)); 
for all d in Duration ( for all r in Real( 

r = float(u) ==> dUsec(u) == Durationl(r); ))); 
constants >= 0 /* constrain value range to be non-negative 7 
endnewtype Usee; 

1* Time Unit sort - (1 * TU) = (1024 * Usee) 7 
newtype TU inherits Integer operators all; 
adding operators 
dTU : TU -> Duration; 
tTU : TU -> Time; 
tuTime : Time -> TU; 
u2TU :Usec->TU; 
tu2U : TU ■> Usee; 
axioms for all k in TU( for all t in Time( for all r in Real( 
r = float(k) ==> tTU(k) == Time!(Duration!(1024 * r)); 
t = Time!(Duration!(r)).and k = (fix(r) / 1024) ==> k == tuTime(t);)); 
for all d in Duration( for all r in Real( 

r = fioat(k) ==> dTU(k) •= Durational 024 * r);)); 
for all u in Usec( u2TU(u) == u / 1024; tu2U(k) == k * 1024; )); 
constants >= 0 /* constrain value range to be non-negative 7 
endnewtype TU; 
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Package macsorts 



Generator for 0-origin String sorts (adapted from 2.105, Annex A 
. « f 

r StringO(sort, nullSymbol) can define strings of any sort. */ 
/* These strings are indexed starting from 0 rather than 1. 7 
r Sorts defined by StringO have the normal String operators, plus 7 
/* Tail (all but first item), Head (all but last item), and 7 
I* aggregators S2, S3, S4, S6, S8 (make fixed length strings). 7 
generator StringO(type Item, literal Emptystring) 

literals Emptystring; 

operators 

MkString : Item -> StringO; /* make a string from an item 7 
Length : StringO -> Integer; /* length of string 7 
First : StringO -> Item; /* first item in string */ 
Tail : StringO -> StringO; /* all but first item in string 7 
Last : StringO -> Item; /* last item in string */ 
head : StringO -> StringO; /* all but last item in string 7 
7r : StringO, StringO -> StringO; /* concatenation 7 
Extract! : StringO, Integer -> Item; r get item from string 7 
Modify! : StringO, Integer, Item -> StringO; F modify string 7 
SubStr : StringO, Integer, Integer -> StringO; 

f SubStr(s,i,j) is stringO of length j starting at stringO(i) 7 
S2 : Item, Item -> StringO; S3 : Item, Item, Item -> StringO; 
S4 : Item, Item, Item, Item -> StringO; 
S6 : Item, Item, Item, Item, Item, Item -> StringO; 
S8 : Item, Item, Item, Item, Item, Item, Item, Item -> StringO; 
r axioms continued on next page... 7 

endgenerator StringO; 



3106_d\StringO(31) 
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Package macsorts 3107_a\StringO(31) 

i ^ . , , ... — , — 

• i\ r StringO axioms V K 

| 1 /* for all itemO.iteml ,item2,item3,item4 I item5,item6,item7 in ltem( 

I J for all s, s1 , S2, S3 in String0( for all i, j in lnteger( 

constructors are Emptystring, MkString, and 7/"; 
equalities between constructor terms 
s // Emptystring == s; Emptystring // s s; 
(s1 // S2) // S3 == s1 // (S2 // S3); 
definition of Length by applying it to all constructors 
type String Length(Emptystring) == 0; 
type String Length(MkString(itemO)) == 1; 
type String Length(s1 // S2> == Length(sl) + Length(S2); 
definition of Extract! by applying it to all constructors, 
Extract!(MkString(itemO), 0) == itemO; 
i < Length(sl) ==> Extract!(s1 // S2, i) == Extract!(s1, i); 
i >= Length(sl) ==> Extract!(s1 //S2, i) == Extract!(S2, i - Length(sl)); 
i < 0 or i >= Length(s) ==> Extract!(s, i) == error!; 
definition of First and Last by other operations 
First(s) == Extract!(s t 0); 
Last(s) == Extracts, Length(s) - 1); 
definition of substr(s,i,j) by induction on j, 
i >= 0 and i <= Length(s) ==> SubStr(s, i, 0) == Emptystring; 
i >= 0 and j > 0 and i + j <= Length(s) ==> SubStr(s, i, j) == 

SubStr(s, i, j - 1) // MkString(Extract!(s ( i + j - 1)); 
i < 0 or j < 0 or i + j > Length(s) ==> SubStr(s f i, j) == error!; 
definition of Modify!, Head, Tail, Sx by other operations 
Modify!(s, i, itemO) == SubStr(s, 0, i) // MkString(ttemO) // 

SubStr(s, i + 1, Length(s) - i - 1); 
head(s) == SubStr(s, 0, Length(s) - 1); 
Tail{s) == SubStr(s, 1, Length(s) - 1); 
S2(item0, iteml) == MkString(itemO) // MkString(iteml); 
S3(item0, iteml, item2) == 

MkString(itemO) // MkString(iteml) // MkString(item2>; 
S4(item0, iteml, item2, item3) == 
MkString(itemO) // MkString (iteml) // MkString(item2) // 
MkString(item3); 
S6(item0, iteml, item2, item3, item4, itemS) == 
MkString(itemO) // MkString (iteml ) // MkString(item2) // 
MkString(item3) // MkString(item4) // MkString(itemS); 
S8(item0, iteml, item2, item3, item4, itemS, item6, item7) == 
MkString(itemO) // MkString(iteml)// MkString(item2) // 
MkString(item3) // MkString(item4) // MkString(itemS) // 
MkString(item6) // MkString(item7); ))); 
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Package macsorts 



3108_d\Bitstring(31) 



ASN.1-style BIT sort (from Z.105, Annex A) 



7 



/* Bit is a subtype of Boolean - bit values 0 and 1 are 
I* not numerals and cannot be used with Integer operators 7 
newtype Bit inherits Boolean 

literals 0 = false, 1 = true; operators all; endnewtype Bit; 



*********** ***** * 



ASN.1-style BIT STRING sort (adapted from Z.105, Annex A; 



=> s1 == S2; 



/* Bitstrings are 0-origin strings of Bit. Z.105 uses ASN.1 -style 7 
r literals in binary ('101 VB) or hexadecimal ('D3'H), but this V, 
/* syntax is not accepted for Z.100 string literals. Therefore, 7 
I* this version provides only hexadecimal literals OxOO-OxFF. 7 
/* Bitstring operators '=>', 'not', 'and', 'or*, and 'xor' act 7 
/* bitwise, with the length of the result string equal to the 7 
r length of the longest (or only) source string. 7 
newtype Bitstring StringO(Bit, ") 
adding literals macro Hex_Literals; 
operators 
"not" : Bitstring •> Bitstring; 
"and" : Bitstring, Bitstring -> Bitstring; 
"or" : Bitstring, Bitstring -> Bitstring; 
"xor" : Bitstring, Bitstring -> Bitstring; 
"=>" : Bitstring, Bitstring -> Bitstring; noequality; 
axioms macro Hex_Axioms; 
for all s r s1, S2, S3 in Bitstring( 
s = s == true; s1 = S2 == S2 = s1; 
s1 /= S2 not (s1 = S2); s1 = S2 == true - 
((s1 = S2) and (S2 = S3)) ==> s1 = S3 == true; 
((s1 = S2) and (S2 /= S3)) ==> s1 = S3 == false; 
for all b, b1,b2 in Bit( 
not (") == n ; 

not (MkString(b) // s) == MkString(not (b)) // not (s); 
" and " == 

Length(s) > 0 ==> " and s == MkString(O) and s; 
Length(s) > 0 ==> s and " -= s and MkString(O); 
(MkString(bl) // s1) and (MkString(b2) // S2) == 

MkString(b1 and b2) // (s1 and S2); 
s1 or S2 == not (not s1 and not S2); 
s1 xor S2 == (s1 or S2) and not (s1 and S2); 
s1 S2 == not (not s1 and S2);)); 
map for all b1, b2 in Bitstring literals( 
for all bs1, bs2 in Charstring literals( 
/* connection to the String generator 7 
for all b in Bit literals( 

spelling(bl) = // bs1 // bs2 // ,m , 
spelling(b2) = // bs2 // spelling(b) = bs1 
==> b1 == MkString(b) // b2; ))); 
endnewtype Bitstring; 
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Package macsorts 3109_d\Octetstring(3l) 

r -» | . 

' i\ / " * K 

| * OCTET sort (influenced by Z. 105, Annex A) 

L I " * * / 

/* Octet is a subtype of Bitstring where length always =8. V 
/* 2.105 adds a "size" keyword to SDL and defines Octet with V 
/* "... constants size (8) ..." to impose this length constraint. */ 
/* Here Octet relies on proper use maintain lengths as multiples */ 
7* of 8. Proper length strings are created by the hexadecimal V 
r Bitstring literals (e.g. 0xD5) and operator mkOctet: 7 
/* o:= mkOctet(i) converts a non-negative Integer (mod 256) V 
T to an Octet (exactly 8 bits) */ 

/* i:= octetVal(o) converts an Octet to an Integer (0:255) */ 
/* o:= flip(o) reverses bit order of the Octet V 
r (0<->7, 1<->6, 2<-->5 ( 3<->4) 7 

newtype Octet inherits Bitstring operators all; 
adding operators 

mkOctet : Integer -> Octet; 

octetVal : Octet -> Integer; 

flip : Octet -> Octet; 
axioms 

for all i in lnteger( for all z in Octet( 

i = 0 ==> mkOctet(i) == S8(0, 0, 0, 0, 0, 0, 0, 0); 
i = 1 ==> mkOctet(i) == S8(1, 0 ( 0, 0, 0, 0, 0, 0); 
i > 1 and i <= 255 ==> mkOctet(i) == 

SubStr((First(mkOctet(i mod 2)) // mkOctet(i / 2)), 0, 8); 
i > 255 ==> mkOctet(t) == mkOctet(i mod 256); 
j < o ==> mkOctet(i) == error!; 
z = MkString(O) ==> octetVal(z) ==0; 
z = MkString(1) ==> octetVal(z) ==1; 
Length(z) > 1 and Length(z) <= 8 ==> 

octetVal(z) == octetVal(Ftrst(z)) + 

(2 * (octetVal(SubStr(z, 1, Length(z) - 1)))); 
Length (z) > 8 ==> octet Val(z) == error!; 
flip(z) == S8(z(7) t z(6),z(5) I z(4),z(3),z(2),z(1),z(0)); )); 
endnewtype Octet; 
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OCTET STRING sort (somewhat influenced by Z. 105, Annex 

r Octetstrings are 0-ORIGIN strings of Octet, NOT 1 -ORIGIN 7 
/* strings like Octet_String in Z.105 (hence the name change). */ 
/* Octetstring has conversion operators to and from Bitstring, 7 
/* and integer to Octetstring. Octetstring literals are "null" 7 
r and 1-4, 6, 8 item 0x00 strings 01, 02, 03, 04, 06, 08. 7 
newtype Octetstring String0(Octet, null) 

adding literals 01, 02, 03, 04, 06, 08; 

operators 

B_S : Octetstring -> Bitstring; r name changed from Z.105 7 
0_S : Bitstring -> Octetstring; /* name changed from Z.105 7 
mkOS : Integer.lnteger -> Octetstring; t mkOS(i1,i2) returns 7 

/* mkstring(mkOctet(i1)) padded (0x00) to length i2 7 
mk2octets : Integer -> Octetstring; /* 16-bit int to 2-octets 7 
axioms 
for all b, b1, b2 in Bitstring( 
for all s in Octetstring( for all o in Octet( 
B_S(null) « null; 0_S(null) == null; 
B_S(MkString(o) // s) == o // B_S(s); 
Length(bl) > 0, Length(bl) < 8 ==> 

O.S(b1) == MkString(b1 or 0x00); /* expand b1 to 8 bits 7 
b == b1 // b2, Length(bl) = 8 ==> 
0_S{b) == MkString(bl) // 0_S(b2); 
for all i, k in lnteger( 
k = 1 ==> mkOS(i, k) == MkString(mkOctet(t)); 
k > 1 ==> mkOS(i. k) == mkOS(i, k - 1) // MkString(OxOO); 
k <= 0 ==> error!; 

mk2octets(i) == MkString(mkOctet(i mod 256)) // 
MkString(mkOctet(i / 256)); ); 
01 == MkString(OxOO); 02 == 01 // 01; 
03 == 02 II 01 ; 04 == 02 // 02; 
06 == 04 // 02; 08 " 04 // 04; ))); 
map for all 01 , 02 in Octetstring literals( 
for all b1, b2 in Bitstring literals( 
spelling(Ol) = spelitng(bl), spelling(02) = spelling(b2) 
==> 01 = 02 == b1 = b2; )); 
endnewtype Octetstring; 
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r— ______ i — " ' — '■' 

] "I * MAC Address sorts 

I J — — ~. *.«*.* , 

/* MacAddr is a subtype of Octetstring with added operators: 7 
I* isGroup(m) =true if given a group address 7 
/* isBcst(m) =true if given the broadcast address 7 
/* isLocal(m) =true if given a locally-administered address 7 
r adrOs(m) converts MacAddr to Octetstring 7 
r MAC addresses must be defined to be exactly 6 octets long, 7 
/* typically using the S6 operator or nullAddr synonym. 7 
newtype MacAddr inherits Octetstring operators all; 
adding operators 
isGroup : MacAddr -> Boolean; 
isBcst : MacAddr -> Boolean; 
isLocal : MacAddr -> Boolean; 
adrOs : MacAddr -> Octetstring; 
axioms 
for all m in MacAddr( 
(Length(m) = 6) and ((Extract!(m ( 0) and 0x01) = 0x01) ==> isGroup(m) == true; 
(Length(m) = 6) and ((Extract!(m,0) and 0x01) = 0x00) ==> isGroup(m) == false; 
(Length(m) = 6) and (m = S6(0xFF,0xFF,0xFF,0xFF,0xFF,0xFF)) ==> isBcst == tme; 
(Length(m) = 6) and (m/= S6(0xFF,0xFF,0xFF,0xFF,0xFF,0xFF)) ==> isBcst == false; 
(Length(m) = 6) and ((Extract!(m,0) and 0x02) = 0x02) ==> isLocal == true; 
(Length(m) = 6) and ((Extract!(m,0) and 0x02) = 0x00) ==> isLocal == false; 
Length(m) /= 6 ==> error! f* common error! term 7; 
for all o in Octetstring(m = MacAddr!(o) == adrOs(m) = o; )); 
endnewtype MacAddr; 

newtype MacAddrSet powerset( MacAddr) endnewtype MacAddrSet; 
synonym bcstAddr MacAddr = /* Broadcast Address V 

«type MacAddr» S6(0xFF,0xFF,0xFF,0xFF,0xFF,0xFF); 
synonym nullAddr MacAddr = /* Null Address 7 

« type MacAddr» S6(0x00,0x00,0x00,0x00 t 0x00,0x00); 



BSS description sorts 
******************* *************** ****-****** *>•**••*•******•*»* **** J 

r BssDscr is used with MlmeScan .confirm and MlmeJoin.request 7 
newtype BssDscr struct 
bdBssId MacAddr; 

bdSsId Octetstring; r 1 <= length <= 32 7 
bdType BssType; 

bdBcnPer TU; /* beacon period in Time Units 7 
bdDtimPer Integer; /* DTIM period in beacon periods 7 
bdTstamp Octetstring; r 8 Octets from ProbeRsp/Beacon 7 
bdStartTs Octetstring; /* 8 Octets TSF when rx Tstamp 7 
bdPhyParms PhyParms; f empty if not needed by PHY 7 
bdCfParms CfParms; /* empty if not CfPollable/no PCF 7 
bdlbssPamis IbssParms; T empty if infrastructure BSS 7 
" bdCap Capability; r capability information 7 
bdBrates Ratestring; /* BSS basic rate set 7 
endnewtype BssDscr; 

newtype BssDscrSet powerset( BssDscr) endnewtype BssDscrSet; 
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3111_d\TupleCache(31) 



Duplicate filtering support sorts 



'7 



syntype FragNum = Integer /* Range of possible fragment numbers */ 

constants 0:sMaxFragNum endsyntype FragNum; 
syntype SeqNum = Integer I* Range of possible sequence numbers 7 

constants 0:4095 endsyntype SeqNum; 
newtype Tuple struct /* for duplicate filtering & defrag mentation 7 
full Boolean; /* =true if Tuple contains valid info 7 
ta MacAddr; /* transmitting station address (Addr2) 7 
sn SeqNum; f* Msdu/Mmpdu sequence number 7 
fn FragNum; /* most recent Mpdu fragment number 7 
tRx Time; /* reception time (endRx of fragment) 7 
default (. false, nullAddr, 0, 0, 0 .); 
end newtype Tuple; 



operator > 

clearTupleCacrm 



operator N 

searchTupleCach a 



operator N 

updateTupleCachs 



**#*****#********«**#»•«*• 



TupleCache support sorts 



'7 



r Number of TupleCache entries and associated index range 7 
synonym tupleCacheSize Integer = 32; r this value is an example, 

TupleCache size is implementation dependent 7 
syntype Cachelndex = Integer constants 1 :tupleCacheSize 

endsyntype Cachelndex; 
I* TupleCache array 7 

(* cache:= ClearTupleCache(cache) to initialize cache 7 
/* cache:= UpdateTupleCache(cache, addr, seq, frag, endRx) 7 
r if <addr,seq> is already cached, updates frag 7 
r rf <addr,seq> not cached, fills an empty entry 7 
/* or replaces an entry using an unspecified algorithm 7 

P SearchTupleCache(cache, addr, seq, frag) 7 
/* returns true if specified <addr, seq, frag > in cache 7 

newtype TupleCache Array( Cachelndex, Tuple); 
adding operators 
ClearTupleCache : TupleCache -> TupleCache; 

SearchTupleCache : TupleCache, MacAddr, SeqNum, FragNum -> Boolean; 

UpdateTupleCache : TupleCache, MacAddr, SeqNum, FragNum, Time -> 
TupleCache; 
operator ClearTupleCache; 

fpar cache TupleCache; returns TupleCache; referenced; 
operator SearchTupleCache; 

fpar cache TupleCache, taddr MacAddr, tseq SeqNum, tfrag FragNum; 

returns Boolean; referenced; 
operator UpdateTupleCache; 

fpar cache TupleCache, taddr MacAddr, tseq SeqNum, tfrag FragNum, 

tnow Time; returns TupleCache; referenced; 
endnewtype TupleCache; 
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Operator clearTupleCache 



CtearCache_1a(1) 



; fpar i\ 
cache TupteCacheM 
returns TupleCache ; j 



del k Cachelndex 



/* This procedural operator is K 
part of sort TupleCache. 

cache: = clearTupleCache(cache) 
marks all entries in cache as empty. V 



k:= 1 



k:=k+1 



cache(k)!full:= 
false 



i 

J 



Mark all cache 
"'entries as empty. 




(=tupleCacheSize) 




cache 
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Operator searchTupleCache 



SearchCache_1a(1) 



; fpar i \ 

cache TupleCacheV, 
taddr MacAddr, 
tseq SeqNum, 
tfrag FragNum ; 

returns Boolean ; 



/* This procedural operator is K 
part of sort TupleCache. ^ 

hit:= searchTupleCache( cache, addr, seq, frag) 
returns hit=true if an entry in cache has 

(ta=addr) and (sn=seq) and (fn=frag); 
else returns hit=false. V 



del k Cachelndex ; 
del result Boolean 




k:= k+1 



Search for exact ■ 
[TA.SeqNum, FragNum} r - - 
match at non-empty ! 
cache entries. J 



result:= 




(cache(k)!sn=tseq) 


(cache(k)!ta= 




and 


taddr) and 




(cache(k)!fn=tfrag) 




and cache(k)tfull 




(=tupleCacheSize) 
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Operator updateTupleCache 



UpdateCache_1b(1) 



; fpar i\ 
cache TupleCache*, ^ 
taddr MacAddr, 
tseq SeqNum, 
tfrag FragNum, 
tnow Time ; 

returns TupleCache 



del k Cachelndex 
dct test Boolean ; 
del temp Tuple ; 



3 



k:= k+1 



k:= 1 



temp:= 
cache(k) 



(false) 




/* This procedural operator is N 
part of sort TupleCache. ^ 

cache:= updateTupleCache 
(addr, seq, frag, time) 
First searches cache for an entry, 
matching the base frame, so that 

(ta=addr) and (sn=seq). 
If such an entry exists, that 
entry is updated in place with 

(fh:= frag) and (tRx;= time). 
If no such entry is found, a free 
entry, or a non-free entry selected 
using an unspecified algorithm, is 
used for this frame, storing 

(ta:= addr) and (sn:= seq) and 

(fn:= frag) and (tRx:= time). 7 



test:=(temp!ta= 

taddr) and 
(temp?sn=tseq) 



Select cachelndex for new 
entry if no {TA.SeqNum} 
match. If possible, use an 
empty location, otherwise 
choose an entry to replace 
an entry selected based 
on unspecified criteria. 




> If a match is found 
-iwith {TA.SeqNum}, 
! update FragNum 
[and tRx for that 
i entry rather than 
(Creating a new 
] (redundant) entry. 



*k:= index to 
use for new 
cache entry' 



temp!full:=true, 
temp!ta:=taddr, 
temp!sn:=tseq 



temp!fn:=tfrag, 
temp!tRx:=tnow 



cache(k):= 
temp 




cache 
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3112_d\Counter(31) 



32-bit Counter sort and Integer string sort 



'7 



I* This sort used for MIB counters, needed because SDL Integers 7 
/* have no specified maximum value. inc(counter) increments the 7 
/* counter value by 1, with wraparound from (2 A 32)-1 to 0. 7 

newtype Counter32 inherits Integer operators all; 
adding operators 

inc : Counter32 -> Counter32; 
axioms 
for all c in Counter32 ( 
c < 4294967295 -=> inc(c) == c + 1; 
c >= 4294967295 ==> inc(c) == 0; ); 
endnewtype Counter32; 

r String (1 -origin) of Integer 7 
newtype Intstring String( Integer, nolnt); endnewtype Intstring; 
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Generator for Queue sorts 



3113_d\Queue(31) 



'7 



/* The Queue generator is derived from the StringO generator 7 
/* to create Queues of any sort. Queues operators are: */ 
/* Qfirst(queue,item) adds item as the first queue element 7 
/* Qlast(queue.item) adds item as the last queue element */ 
/* and the StringO operators Length, //. First, Last, Head, Tail */ 
/* Because operators can only return a single value, removing an 7 
/* element from a queue is a 2-step process: 7 
/* dequeue first: item:=First(queue); queue:=Tail(queue); 7 
/* dequeue last: item:=Last(queue); queue:=Head(queue); 7 
generator Queue(type Item, literal Emptyqueue) 

literals Emptyqueue; 

operators 

MkQ : Item -> Queue; /* make a queue from an item 7 

Length : Queue -> Integer; /* number of items on queue 7 

First : Queue -> Item; T first item on queue 7 

Qfirst : Queue, Item •> Queue; r add item as first on queue 7 

Tail : Queue -> Queue; /* all but first item on queue 7 

Last : Queue -> Item; I* last item on queue 7 

Qlast : Queue, Item -> Queue; /* add item as last on queue 7 

head : Queue -> Queue; I* all but last item on queue 7 

"/r : Queue, Queue -> Queue; /* concatenation 7 

Extract! : Queue.integer -> item; /* copy item from queue 7 

Modify! : Queue.lnteger.ltem -> Queue; /* modify item in queue 7 

SubQ : Queue.lnteger.lnteger -> Queue; 

r SubQ{q,i,j) queue of length j starting from queue(i) 7 
axioms 

for all itemO in ltem( for all q, q1. q2, q3 in Queue( 

for all i, j in lnteger( 
f* constructors are Emptyqueue, MkQueue, and 7/"; 7 
I* equalities between constructor terms 7 

q // Emptyqueue == q; Emptyqueue // q == q; 
(q1 // q2) // q3 == q1 // (q2 // q3); 
r definition of Length by applying it to all constructors 7 
type Queue Length(Emptyqueue) == 0; 
type Queue Length(MkQueue(itemO)) == 1 ; 
type Queue Length(q1 // q2) == Length{q1) + Length(q2); 
r definition of Extract! by applying it to all constructors, 7 
Extract!(MkQueue(itemO), 0) == itemO; 
i < Length(ql) ==> Extract!(q1 // q2, i) == Extract!(q1, i); 
t >= Length(ql) ==> Extract!(q1 // q2, i) == Extract!(q2. i - Length(ql)); 
i < 0 or i >= Length(q) ==> Extract!(q, i) == error!; 
r definition of First and Last by other operations 7 

First(q) == Extract!(q, 0); Last(q) == Extract!(q, Length(q) - 1); 
r definition of SubQ(q,i,j) by induction on j, 7 

i >= 0 and i <= Length(q) ==> SubQ(q, i, 0) == Emptyqueue; 
i >= 0 and j > 0 and i + j <= Length(q) ==> SubQ(q, i, j) == 

SubQ(q, i, j - 1) // MkQueue(Extract!(q, r + j - 1)); 
i < 0 or j < 0 or i + j > Length(q) ==> SubQ(q,i,j) == error!; 
/* define Modify!, Head, Tail, Qfirst, Qlast by other ops 7 
Modify!(q, i, itemO) == SubQ(q, 0, I) // 

MkQueue(itemO) // SubQ(q ( i + 1, Length(q) - i - 1); 
head(q) == SubQ(q, 0, Length(q) - 1); 
Tqil(q) == SubQ(q, 1, Length(q) - 1); 
Qfirst(q, itemO) == MkQueue(itemO) //q; 
Qlast(q, itemO) == q // MkQueue(itemO); ))); 
endgenerator Queue; 
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operator 

qSearch 



Fragmentation support sorts 



***************** 



fCur 
fAnc 

eol 



/* Array to hold up to FragNum fragments of an Msdu/Mmpdu 7 
newtype FragArray Array(FragNum, Frame); endnewtype FragArray; 
r FragSdu structure is for OUTGOING MSDUs/MMPDUs (called SDUs) 7 
/* Each SDU, even if not fragmented, is held in an instance of 7 
/* this structure awaiting its (re)transmission attempt(s). */ 
/* Transmit queue(s) are ordered lists of FragSdu instances. */ 
newtype FragSdu struct 

fTot FragNum; 1* number of fragments in pdus FragArray */ 
FragNum; I* next fragment number to send */ 
FragNum; /' next fragment to announce in ATIM or TIM 
when fAnc > fCur, pdus(fCur)+ may be sent */ 
Time; f* set to (now + dUsec(aMaxTxMsduLifetime)) 
when the entry is created 7 
sqf SeqNum; /* SDU sequence number, set at 1st Tx attempt 7 
src Integer; /* short retry counter for this SDU */ 
Ire Integer; /* long retry counter for this SDU */ 
dst MacAddr; r destinaton address 7 
grpa Boolean; /* =true if RA (not DA) is a group address 7 
psm Boolean; r =true if RA (not DA) may be in pwr_save */ 
resume Boolean; /* =true if fragment burst being resumed */ 
cnfTo Pld; /* address to which confirmation is sent 7 
txrate Rate; /* data rate used for initial fragment 7 
cf CfPriority; /* requested priority (from LLC) 7 
pdus FragArray; /* array of Frame to hold fragments */ 
endnewtype FragSdu; 
r Queue of FragSdu 7 

I* for power save buffers, etc., searchable with Qsearch operator: 7 
I* index:= Qsearch(queue, addr) where queue is an SduQueue, 7 
I* index identifies the first queue entry at which 7 
/* entryldst = addr; or as -1 if no match (or queue empty). 7 
newtype SduQueue Queue(FragSdu, emptyQ); 

adding operators 
qSearch : SduQueue, MacAddr -> Integer; 

operator qSearch; 
fpar que SduQueue, val MacAddr; returns Integer; referenced; 
endnewtype SduQueue; 
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Operator Qsearch 



| ; fpar i \ 

i que SduQueue, 
! val MacAddr ; 
J returns result Integer ; 



Qsearch_1a(1) 



del k, Ing Integer 




/* This procedural operator is N 
part of sort SduQueue. ^ 

index:= Qsearch(queue, addr) 
returns index of the first queue 
entry at which (entrytdst = addr); 
returns -1 if no match found. 
Also returns -1 for empty queue. V 



lng:= 
length(que) 






k:= 


= 0 





(false) 


k:= k + 1 








result 
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3115_d\Defragment(31) 



operator 

ArAge 




operator 

ArSearch 



Def rag mentation support sorts 



7 



/* The PartialSdu structure is for INCOMPLETE MSDUs/MMPDUs */ 

/* (generically SDUs) for which at least 1 fragment has been 7 

/* received. Unfragmented SDUs are reported upward immediately, */ 

/* and are never stored in instances .of this structure. 7 

newtype PartialSdu struct 

inUse Boolean; r =true if this instance holds any fragments 7 
rta MacAddr; /* transmitting station (Addr2) 7 
rsn SeqNum; /* SDU sequence number 7 
rCur FragNum; /* fragment number of most recent Mpdu 7 
reol Time; /* (now+dUsec(aMaxReceiveLifetime) @ 1st Mpdu 7 
rsdu Frame; /* buffer where Mpdus are concatenated 7 
default (. false, nuliAddr, 0, 0, 0, null .); 
endnewtype PartialSdu; 

newtype PartialSduKeys struct /* if aPrivacyOptionlmplemented=true 7 
wDefKeys Key Vector; I* default keys when 1st frag received */ 
wKeyMap KeyMapArray; /* key mappings when 1st frag received * 
wExclude Boolean; /* a ExcludeUn encrypted @ 1st frag rx 7 

endnewtype PartialSduKeys; 

/* Number of entries in defrag mentation array at this station. 7 
/* The value is implementation dependent (min=3, see 9.5). 7 
synonym defragSize integer = 6; 
syntype defrag Index = Integer constants 1:defragSize 
endsyntype defraglndex; 

/* Array of PartialSdu for use defragmenting Msdus and Mmpdus. 7 
r Searchable using the ArSearch operator 7 
/* index:= ArSearch(array, addr, seq, frag) 7 
/* where index is returned to identify the first element for which 7 
P ((inUse = true) and (entryirta = addr) and (entrylrsn = seq) 7 
/* and (entrytrCur = (frag-1)); or as =1 if no match found. 7 
I* index:= ArFree(array) returns the index of a free entry, 7 
/* or -1 if no entries free. May free an entry, selected using 7 
/* an unspecified algorithm, to avoid returning -1. 7 
/* array: = ArAge(array, age) 7 

/* frees where (entry!eol < age), also used to clear array. 7 
newtype Defrag Array Array( defraglndex, PartialSdu); 
adding operators 
ArSearch : DefragArray, MacAddr, SeqNum, FragNum -> Integer; 
Arfree : DefragArray -> Integer; 
ArAge : DefragArray, Time -> DefragArray; 
operator ArSearch; 
fpar ar DefragArray, adr MacAddr, seq SeqNum, frg FragNum; 
returns Integer; referenced; 
operator ArFree; fpar ar DefragArray; returns Integer; referenced; 
operator ArAge; fpar ar DefragArray, age Time; 
returns DefragArray; referenced; 
endnewtype DefragArray; 

newtype Defrag KeysArray Array( defraglndex, PartialSduKeys); 
endnewtype DefragKeysArray; 
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Operator ArAge 



ArAge_1a(1) 



];fpar i\ 
» ar Def rag Array, " ] 
! age Time ; i 
J returns DefragArray ; | 



/* This procedural operator K 
is part of sort DefragArray. ^ 

array:= ArAge(array, age) 
frees entryleol < age. This is 
used both for the aging function 
and to clear the DefragArray. */ 



del k Def rag Index ; 
del te Boolean ; 
del temp PartialSdu 




k:= k+1 



Mark alt entries 
with end-of-life 
(reol) earlier 
than specified 
as not in use. 



<— 

temp;=ar(k), 

te:= 
tempiinUse 




(false) 



(false) 



temp!inUse:= 

false, 
ar(k):= temp 



else 




(=defragSize) 
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Operator ArFree 



Arfree_1b{1) 



; fpar i\ 
ar Def rag Array" ;) 
returns Integer ; | 



del k Def rag Index 
del result Integer ; 
del te Boolean ; 
del temp PartialSdu 



k:= 1 



k:= k+1 



temp:=ar(k) t 

te:= 
tempiinUse 




(true) 



te 



Return index 1 
of a free entry \~ 
if possible. \ 



(false) 



result:= k 




/* This procedural operator is \ 
part of the sort DefragArray. ^ 

index:= ArFree(array) 
returns index of an unused entry 
in the array. If all entries are used, 
either returns -1, or selects an 
arbitrary entry to free in order to 
return a usable index. Decision 
criteria for case of no free entries 
are implementation dependent. */ 



else 



(=defragSize) 



result:* -1 





(false) 




'k:= index 






of entry to 






force free' 












ar(k)!inUse:= 






false, 






result:* k 





• This decision is 
i implementation 
[dependent. 



> Select an entry to 
-ire-use based on 
| unspecified criteria. 




result 
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Operator ArSearch 

fpar 7\ 
ar Def rag Array ,) 
adr MacAddr, 
seq SeqNum, 
frg FragNum ; 
[returns Integer ; 



ArSearch_1a(1) 



* This procedural operator is K 
part of sort DefragArray. ^ 

index:= ArSearch(array, addr, seq, frag) 
where array is a DefragArray; 
index is returned to identify the first element 
for which (inUse=true) and (entry!rta=addr) and 

(entry!rsn=seq) and (entry!rCur=frag-1); 
index is returned =1 if no match is found. */ 



dci k Defrag Index ; K 
del result Integer ; 
del te Boolean ; 
del temp PartialSdu 



k:= 1 




temp:=ar(k), 

te:= 
tempiinllse 




(false) 



Search for first 
element where 
(inUse=true) and 
(rta=adr) and 
(rsn=seq) and 
(rCur=(frg-1)) 



te:= 




(templrsn = seq) 


(temp!rta= 




and 


adr) and 




(tempirCur 




= (frg-1)) 



(false) 



(true) 



result:= k 





else 



(=defragSize) 



result 
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Package macsorts 



3116_d\Crc_Wep(31) 



(I 



operator 

crc32 



CRC-32 sorts (for FCS and ICV) 



. **.********...***********************.*********, 

/* Crc is a subtype of Octetstring with added operators: */ 
/* crc:= Crc32{crc, octet) 7 

I* updates the crc value to include the new octet, and 7 
/* Mirror(crc), which returns a Crc value with the order 7 
I* of the octets, and of the bits in each octet, reversed for 7 
/* MSb-first transmission (see 7.1.1). Crc variables must have 7 
/* exactly 4 octets, which is done using initCrc or S4. 7 
newtype Crc inherits Octetstring operators all; 
adding operators 
Crc32 : Crc, Octet -> Crc; 
mirror : Crc -> Octetstring; 
operator Crc32; fpar crcin Crc, val Octet; returns Crc; referenced; 
axioms for all c in Crc( 

mirror(c) == S4(flip(c(3)),flip(c(2)),flip(c(1)), flip(c(0))); ); 
endnewtype Crc; 

synonym initCrc Crc = /* Initial Crc value (all 1s) 7 

« type Crc» S4(0xFF,0xFF,0xFF,0xFF); 
synonym goodCrc Crc = /*■ Unique remainder for valid CRC-32 7 

« type Crc» S4(0x7B.0xDD,0xO4,0xC7); 



operator 

keyLookup 



WEP support sorts 



****** **** ************** 



1\ 



***********! 



***********: 



"7 



syntype Keylndex = Integer constants 0:3 endsyntype Keylndex; 
newtype PrngKey inherits Octetstring operators all; 
adding literals nullKey; r nullKey is not any of 2 A 40 key values 7 
axioms nullKey == null; default nullKey; endnewtype PrngKey; 
newtype Key Vector f* vector of default WEP keys 7 
Array( Keylndex, PrngKey); endnewtype KeyVector; 

f Number of entries in aWepKeyMappings array at this station. 

/* implementation dependent value, minimum=10 (see 8.3.2). 7 
synonym sWepKeyMappingLength Integer = 10; 
syntype KeyMappingRange = Integer 

constants 1:sWepKeyMappingLength endsyntype KeyMappingRange; 
newtype KeyMap struct r structure used for entries in KeyMapArray 7 

mappedAddr MacAddr; 

wepOn Boolean; 

wepKey PrngKey; 
endnewtype KeyMap; 

/* KeyMapArray used for aWepKeyMapping table; 7 
I* an array of KeyMap indexed by KeyMappingRange, with operator 7 
/* KeyMap := keyLookup(addr, keyMapArray, key MapArray Length) 7 
f* returns the KeyMap entry for the specified addr, or 7 
/* (. nullAddr, false, nullKey .) if no mapping for addr. 7 
newtype KeyMapArray Array ( KeyMappingRange, KeyMap); 
adding- operators 

keyLookup : MacAddr, KeyMapArray, Integer -> KeyMap; 
operator keyLookup; 

fpar luadr MacAddr, kma KeyMapArray, kml Integer; 

returns KeyMap; referenced; 
endnewtype KeyMapArray; 
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Operator Crc32 



crc32_1a(1) 



; fpar i\ 
crcin Crc, " *] 
val Octet ; i 

returns Crc ; ! 



( 




) 








k:= 


= 0 








temp:= 
b_s (crcin) 



k:= k+1 



new:= 
val(k) xor 
last(temp) 



temp:= 
mkstring(new) 
// head(temp) 




(false) T(true) 



temp:= 
temp xor 
feedback 



else 




results 
o_s(temp) 




result 



* This procedural operator is K 
part of sort Crc. 

crc:= Crc32(crc, octet) 
generates CRC-32 polynomial 
LSb-first, for the 8 bits of 
octet into accumulator crc. 7 



del k Integer ; 
del new Bit ; 
del result Crc ; 
del temp Bitstring ; 



/* Bitstring with 1s at bit 
positions with feedback 
terms in CRC-32 polynomial 7 

synonym feedback Bitstring = 
S8(0,1,1,0.1,1,0,1)// 
S8(1,0 ( 1,1,1,0,0,0)// 
S8(1,0.0 ( 0 ( 0,0,1,1)// 
S8(0,0,1 ,0.0,0,0,0) ; 
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Operator keyLookup 



KeyLookup_1a(1) 



; fpar luadr MacAddr, i\ 
kma KeyMapArray, fc ] 
kml Integer ; ■ 

returns KeyMap ; ; 



r This procedural operator is 
part of sort KeyMapArray. 
keyMap:= keyLookup 
(addr, keyMapArray, keyMapArrayLength) 
If an entry is found with mappedAddr=addr, 

keyMap is set to the value of this entry. 
If no entry is found with mappedAddr=addr, 
keyMap is set to (. nullAddr, false, nullKey .) 



del Ik Integer := 1 ; 
del result KeyMap 




luadr = 
kma(lk)! 
nappedAdtJ^ (true) 

(false) 



lk:= Ik + 1 



result:= 
kma(lk) 



(false) 




(true) 



result! 
mappedAddr:= 
null Addr 



result! 
wepOn:= 
false 



result! 
wepKey:= 
nullKey 




result 



» Return first KeyMap 
-i element with correct 
| mappedAddr value. 



If the end of the key 
map array is reached 
without finding addr, 
indicate the lack of 
a mapping by returning 
nullAddr. This avoids 
ambiguity between an 
entry which maps to 
nullKey and nullKey 
being returned due 
to lack of a mapping. 
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Package macsorts 



FRAME sort (the basic definition of fields in MAC frames) 



3117_d\Frame_1(3l) 



/* Frame is a subtype of Octetstring with operators for creating 
/* MAC headers, extracting each of the header fields and some 
/* management frame fields, and modifying most of these fields. 
/* There are operators to create and extract management frame 
/* elements, but no operators for the frame body, IV, ICV, and FCS 
r fields, which are handled directly as Octetstrings. 7 
newtype Frame inherits Octetstring operators all; 
adding operators 

mkFrame : TypeSubtype, MacAddr, MacAddr, Octetstring •> Frame; 

mkCtl : TypeSubtype, Octetstring, MacAddr -> Frame; 

protocolVer : Frame -> Integer; /* Protocol version (2 bits) 7 

basetype : Frame -> BasicType; /* Type field (2 bits) */ 

ftype : Frame -> TypeSubtype; /* Type & Subtype (6 bits) 7 

setFtype : Frame, TypeSubtype -> Frame; 

toDs : Frame -> Bit; /* To DS bit (1 bit) 7 

setToDs : Frame, Bit -> Frame; 

frDs : Frame -> Bit; /* From DS bit (1 bit) 7 

setFrOs : Frame, Bit -> Frame; 

moreFrag : Frame -> Bit; /* More Fragments bit (1 bit) 7 
setMoreFrag : Frame, Bit -> Frame; 
retryBit : Frame -> Bit; r Retry bit (1 bit) 7 
setRetryBit : Frame, Bit -> Frame; 

pwrMgt : Frame -> Bit; /* Power Management bit (1 bit) 7 

setPwrMgt : Frame, Bit -> Frame; 

moreData : Frame -> Bit; r More Data bit (1 bit) 7 

setMoreData : Frame, Bit -> Frame; 

wepBit : Frame -> Bit; /* WEP bit (1 bit) 7 

setWepBit : Frame, Bit -> Frame; 

orderBit : Frame -> Bit; r (strictly}Order{ed) (1 bit) 7 

setOrderBit : Frame, Bit -> Frame; 

durld : Frame -> Integer; /* Duration/ID field (2) 7 

setDurld : Frame, Integer -> Frame; 

addrl : Frame -> MacAddr /* Address 1 (DA/RA] field (6) 7 
setAddrl : Frame, MacAddr -> Frame; 
addr2 : Frame -> MacAddr /* Address 2 [SA/TA] field (6) 7 
setAddr2 : Frame, MacAddr -> Frame; 

addr3 : Frame -> MacAddr /* Address 3 [Bss/DA/SA] field 7 
setAddr3 : Frame, MacAddr -> Frame; 

addr4 : Frame -> MacAddr; r Address 4 [WDS-SA] field (6) 7 

insAddr4 : Frame, MacAddr -> Frame; 

seq : Frame -> SeqNum; /* Sequence Number (12 bits) 7 

setSeq : Frame, SeqNum -> Frame; 

frag : Frame -> FragNum; V Fragment Number (4 bits) 7 

setFrag : Frame, FragNum -> Frame; 

ts : Frame -> Time; /• Timestamp field (8) 7 

setTs : Frame, Time -> Frame; 

mkElem : ElementID, Octetstring -> Frame; /* make element 7 
GetElem : Frame, ElementID -> Frame; /* get element if aval 7 
status : Frame -> StatusCode; /* Status Code field (2) 7 
setStatus : Frame, StatusCode -> Frame; 

authStat : Frame -> StatusCode; /* Status Code in Auth frame 7 
reason : Frame -> ReasonCode; /* Reason Code field (2) 7 

/* Frame* operators continued on next page ...7 



operator 

getElem 



j Gets element 
I from body of 
[Management 
'frame. If the 
[target element 
| is not present 
< an Octetstring 
i of length zero 
| is returned. 
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Package macsorts ; 3118_d\Frame_2(31) 

r ...Frame Sort Operators continued */ N 

, ^ authSeqNum : Frame -> integer /* Auth Sequence Number (2) *r 

i !\ authAlg : Frame -> AuthType; /* Auth Algorithm field (2) 7 
] j beacon Int : Frame -> TU; f* Beacon Interval field (2) */ 

. 1 listenlnt : Frame -> TU; /* Listen Interval field (2) 7 

Aid : Frame -> Asocld; r Association ID field (2) 7 

setAld : Frame, Asocld -> Frame; 

curApAddr : Frame -> MacAddr; /* Current AP Addr field (6) 7 
capA : Frame, Capability -> Bit; f* Capability (Re)Asoc 7 
setCapA : Frame, Capability, Bit -> Frame; 
capB : Frame, Capability -> Bit; r Capability Ben/Probe 7 
setCapB : Frame, Capability, Bit -> Frame; 
keyld : Frame -> Keylndex; /* Key ID subfield (2 bits) 7 
setKeyld : Frame, Keylndex -> Frame; 
operator GetElem; 

fpar fr Frame, el ElementID; returns Frame; referenced; 



/* Frame Sort Axioms 7 T 
axioms 

for all f in Frame( for all a, sa, da, ra, ta, bssa in Mac Add r( 
for all body, dur, sid, info in Octets tring( 
addr1(f)== SubStr(f,4,6); 

setAddr1(f,a) == SubStr(f,0,4) // a // SubStr(f,10,Length(f)-10); 
addr2(f) == SubStr(f,10,6); 

setAddr2(f,a) " SubStr(f,0,10) // a // SubStr(f,16,Length(f)-16); 
addr3(f) " SubStr^^e); 

setAddr3(f,a) == SubStr(f,0,16) // a // SubStr(f,22, Length (f)- 22); 
addr4(f) == SubStr(f,24,6); 

insAddr4(f,a) == SubStr(f,0,24) // a // Su bStr(f ,24 .Length (f)-24); 
curApAddr(f) == SubStr(f,28,6); 
for all ft in TypeSubtype( 
mkFrame(ft, da, bssa, body) == 

ft // 03 // da // dotHMacAddress // bssa // 02 // body; 
(ft = rts) ==> mkCtl(ft, dur, ra) == 

ft // 01 // dur // ra // aStattonID; 
(ft = ps_poll) ==> mkCtl(ft, sid, bssa) == 

ft // 01 // sid // bssa // aStationID; 
(ft = cts) or (ft = ack) ==> mkCtl(ft, dur, ra) == 

ft//01//dur//ra; 
(ft = cfend) or (ft = cfend.ack) ==> mkCtl(ft, bssa, ra) == 

ft // 03 // ra // bssa; 
ftype(f) == MkString(f(0) and OxFC); 
setFtype(f, ft) == Modify!(f, 0, MkString((f(0) and 0x03) or 

ft)); ); 

for all bt in BasicType( basetype(f) == f(0) and OxOC; ); 
for all i in lnteger( 

protocolVer(f) == octetVal(f(0) and 0x03); 

authSeqNum(f) == octetVal(f(26)) + (octetVal(f(27)) * 256); 

durld(f) == octetVal(f(2)) + (octetVal(f(3)) * 256); 

setDurld(f, i) == SubStr(f, 0, 2) // mkOS(i mod 256, 1) // 
mkOS(i / 256, 1) // SubStr(f, 4, Length(f) - 4); ); 
for all e in ElementlD( 

mkElem(e, info) == e // mkOS(Length(info) + 2, 1) // info; ); 

/* Frame Sort Axioms continued on next page ... 7 
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Package macsorts 3119_d\Frame_3(31) 

r -v p — ■ , , 

i i\ /* ... Frame Sort Axioms continued V K 

| for all b in Bit( u 

I __ _J toDs(f)== if (f(1) and 0x01) then 1 else 0 fi; 

setToDs(f, b) == 

Modify!(f, 1 t (f(1) and OxFE) or S8(0,0,0,0,0,0,0,b)); 
frOs(f) " if (f(1) and 0x02) then 1 else 0 fi; 
setFrDs(f, b) == 

Modify!(f. 1, (f(1)and OxFD) or 58(0,0,0,0,0,0,0,0)); 
moreFrag(f) == if (f(1) and 0x04) then 1 else 0 fi; 
setMoreFrag(f, b) == 

Modify!(f, 1, (f(1)and OxFB) or S8(0,0,0,0,0,b,0,0)); 
retryBit(f) == if (f(1) and 0x08) then 1 else 0 ft; 
setRetryBit(f, b) == 

Modify!(f, 1, (f(1) and 0xF7) or S8(0,0,0,0,b,0,0,0)); 
pwrMgt(f) == if (f(1) and 0x10) then 1 else 0 fi; 
setPwrMgt(f, b) == 

Modify!(f, 1, (f(1) and OxFB) or S8(0,0,0,b,0,0,0,0)); 
moreData(f) == if (f(1) and 0x20) then 1 else 0 fi; 
setMoreData(f, b) == 

Modify!(f, 1, (f(1) and OxFB) or S8(0,0,b,0,0,0,0,0)); 
wepBit(f) == if (f(1) and 0x40) then 1 else 0 fi; 
setWepBit(f, b) == 

Modify!(f, 1, (f(1) and OxFB) or S8(0,b,0,0 ,0,0,0,0)); 
orderBit(f) == if (f(1) and 0x80) then 1 else 0 fi; 
setOrderBit(f, b) == 

Modify!(f, 1, (f(1) and OxFB) or S8(b,0,0,0,0,0,0,0)); 
for all c in Capability( 

capA(f.c) == if (B_S(SubStr(f,24,2)) and c) then 1 else 0 fi; 
setCapA(f,c,b) == SubStr(f,0,24) // (B_S(SubStr(f,24,2) and 
(not c)) or (if b then c else 02 fi)) // 
SubStr{f,26,Length(f) - 26); 
capB(f.c) == if (B_S(SubStr(f,34,2)) and c) then 1 else 0 fi; 
setCapB(f.cb) == SubStr(f,0,34) // (B_S(SubStr(f,34,2) and 
(not c)) or (if b then c else 02 fi)) // 
SubStr(f,36,Length(f) - 36); )); 
for all sq in SeqNum( 
seq(f) == (octetVal(f(22) and 0xF0)/16)+(octetVal(f(23)M6)); 
setSeq(f, sq) == SubStr(f, 0, 22) // MkString((f(22) and OxOF) 
or mkOctet((sq mod 16) * 16)) // mkOS(sq / 16, 1) // 
SubStr(f, 24, Length(f) - 24); ); 
for all fr in FragNum( 
frag(f) == octet Val(f( 22) and OxOF); 
setFrag(f, fr) == 

SubStr(f, 0, 22) // MkString((f(22) and OxFO) or 
mkOctet(fr)) // SubStr(f, 23, Length(f) - 23); ); 
for all tm in Time{ 

ts(f) == tUsec( Usec!(octetVal(f(24)) + 
(256 * (octetVal(f(25)) + 
(256 * (octetVal(f(26)) + 
(256 * (octetVal(f(27)) + 
(256 * (octetVal(f(28)) + 
(256 * (octetVal(f(29)) + 
(256 * (octetVal(f(30)) + 
(256 •octetVal(f(31 ))))))))))))))))); 

r Frame Sort Axioms continued on next page ... */ 
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... Frame Sort Axioms continued */ 

setTs(f, tm) == SubStr{f, 0, 24) // mkOS(fix(tm), 1) // 
mkOS((fix(tm) / 256), 1) // mkOS((ftx(tm) / 65536), 1) // 
mkOS((ftx(tm) / 16777216), 1) // 
mkOS((fix(tm) / 4294967296), 1) // 
mkOS(((fix(tm) / 4294967296) / 256), 1) // 
mkOS(({fix(tm) / 4294967296) / 65536), 1) // 
mkOS(({fix(tm) / 4294967296) / 16777216), 1) // 
SubStr(f, 32, Length(f) - 32); ); 
for all stat in StatusCode( 
status(f) == SubStr(f, 26, 2); 
setStatus(f, stat) == 

SubStr(f, 0, 26) // stat // SubStr(f, 28, Length(f) - 28); 
authStat(f) == SubStr(f, 28, 2); ); 
for all rea in ReasonCode( reason(f) == SubStr(f, 24, 2); ); 
for all alg in AuthType( AuthType(f) == SubStr(f, 24, 2); ); 
for all u in TU( 
beaconlnt(f) == octetVal(f(32)) + (octetVal(f(33)) * 256); 
listenlnt(f) == octetVal(f(26)) + (octetVal(f(27)) * 256); ); 
for all sta in Assocld( 
Ald(f) == octetVal(f(28)) + (octetVal(f(29)) * 256); 
setAld(f, sta) == SubStr(f, 0, 28) // mkOS(sta mod 256, 1) // 
mkOS(sta / 256, 1) // SubStr(f, 30, Length(0 - 30); ); 
for all kid in KeytndexRange( 
keyld(f) == octetVal(f(27)) / 64; 

setKeyld(f, kid) == Modify!(f, 27, mkOS(kid * 64)); ); ))); 
endnewtype Frame; 



3120_d\Frame_4(31) 



* ReasonCode sort 



newtype ReasonCode inherits Octetstring operators all; 
adding literals unspec_ reason, auth_not_valid, deauth_lv_ss, 

inactivity, ap_overload, dass2_err, class3_err, 

disas_lv_ss, asoc_not_auth; 
axioms 

unspec_reason == mkOS(1 , 2); auth_not_valid == mkOS(2, 2); 
deauthjv_ss == mkOS(3, 2); inactivity == mkOS(4, 2); 
ap_overtoad == mkOS(5, 2); class2_err == mkOS(6, 2); 
class3_err == mkOS(7, 2); disasjv_ss == mkOS(8, 2); 
asoc_not_auth == mkOS(9, 2); 
endnewtype ReasonCode; 



StatusCode sort 



newtype StatusCode inherits Octetstring operators all 
adding literals successful, unspec_fail, unsup_cap, 
reasoc_no_asoc, fail_other, unsupt_atg, auth_seq_fail, 
chlng_fail, auth_timeout, ap_full, unsup_rate; 
axioms 

successful == mkOS(0, 2); unspec.failure == mkOS(1, 2); 
unsup_cap == mkOS(10, 2); reasoc_no_asoc == mkOS(11, 2); 
fail_other == mkOS(12, 2); unsupt_alg == mkOS(13, 2); 
auth_seq_fail == mkOS(14, 2); chlngjail " mkOS(15, 2); 
authjimeout == mkOS(16, 2); apjull == mkOS(17, 2); 
unsup_rate == mkOS(18, 2); 
endnewtype StatusCode; 



Copyright © 1999 IEEE. All rights reserved. 



307 



ISO/IEC 8802-11: 1999(E) 
ANSI/IEEE Std 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



Operator getElem 



GetElem_1a<1) 



; fpar 
fr Frame, 
el Elementld 

returns Frame 



del k, Ing, n Integer ;[\ 
del info Frame ; ^ 
del te Boolean ; 
del v1 r v2 Octet ; 



( 




) 






n:= length(fr) 



' This is a procedural operator K 
is part of sort Frame. This ^ 
operator extracts an element 
from a Management frame: 

elem:= getElem(fr.el) 
Copies the info field of element 
with element ID el from frame fr 
into elem. If there is no element 
with the specified element ID, 
elem is set to 'null*. 7 




(asoc_req, 
asoc_rsp, 
reasoc_rsp) 



k:=k + 
sMacHdrLng 



te:= n >= k 



(false) 





lng:= 
octetVal(vl) 



I 



info:= 
substr 
(fr,k+2,lng) 




k:= k + 
octetVal 
(v1) + 2 
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Frame Type sorts 



3121_d\FrameType(31) 



/* TypeSubtype defines the full, 6-bit frame type identifiers. V 
I* These values are useful with ftype operator of Frame sort. */ 
newtype TypeSubtype inherits Octetstring operators all; 
adding literals asoc_req, asoc_rsp, reasoc_req, reasoc_rsp, 
probe_req, probe_rsp, beacon, atim, disasoc, auth, deauth, 
ps_poll, rts, cts, ack, cfend, cfend_ack, data, data.ack, 
data_poll, data_poll_ack, null_frame, cfack, cfpoll, cfpolLack; 
axioms 

asoc_req =- MkStringtSSfO.O.O.O.O.O.O.O)); 

asoc_rsp == MkString(S8(0,0,0,0,1, 0,0,0)); 

reasoc_req == MkString(S8(0,0,0,0,0,1,0,0)); 

reasoc_rsp == MkString(S8(0 ,0,0,0, 1,1, 0,0)); 

probe, req == MkString(S8(0,0,0 ,0,0,0,1,0)); 

probe.rsp == MkString(S8(0 ,0,0,0,1 ,0,1 ,0)); 

beacon =~ MkString(S8(0,0,0,0, 0,0,0,1)); 

atim == MkString(S8(0,0,0,0,1, 0,0,1)); 

disasoc == MkString(S8(0,0,0,0,0,1,0,1)); 

auth == MkString(S8(0,0,0,0,1,1,0,1)); 

deauth == MkString(S8(0,0,0,0,0,0,1,1)); 

ps_poll == MkStringfSSfO.O.I.O.O.I.O.I)); 

rts == MkString(S8(0,0,1,0,1, 1,0,1)); 

cts == MkString(S8(0,0,1, 0,0,0,1,1)); 

ack == MkString(S8(0,0,1,0,1,0,1,1)); 

cfend == MkString(S8(0 t 0,1,0,0,1,1,1)); 

cfend.ack == MkString(S8(0,0,1, 0,1 ,1,1,1)); 

data == MkString(S8(0,0,0,1,0,0,0,0)); 

data.ack == MkString(S8(0,0,0,1, 1,0,0,0)); 

data_poll == MkString(S8(0,0 t 0,1,0,1,0,0)); 

data_poll_ack == MkString(S8(0,0,0,1, 1,1,0,0)); 

null_frame == MkString{S8(0,0,0 t 1,0,0,1,0)); 

cfack == MkString(S8(0,0,0,1, 1,0,1,0)); 

cfpoll == MkString(S8(0,0 t 0,1,0,1,1,0)); 

cfpoll.ack == MkString(S8(0,0,0,1,1,1,1,0)); 
endnewtype TypeSubtype; 

BasicTypes defines the 2- bit frame type groups 7 
newtype BasicType inherits Bitstring operators all; 
adding literals control, data, management, reserved; 
axioms 

control " S8(0,0,1 ,0,0,0,0,0); data == S8(0,0,0,1 ,0,0,0,0); 
management == S8(0,0,0,0,0,0,0,0); reserved == S8(0,0,1, 1,0,0,0,0); 
endnewtype BasicType; 
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3122_d\MgmtFields(31) 



ElementlD sort 



/ 

newtype ElementlD inherits Octetstring operators all; 
adding literals eSsld. eSupRates, eFhParms, eDsParms, 

eCfParms, eTim, elbParms, eCtext; 
axioms 

eSstd == mkOS(0, 1); T service set identifier (0:32) 7 
eSupRates == mkOS(1, 1); r supported rates (1:8) V 
eFhParms == mkOS(2. 1); /* FH parameter set (5) */ 
eDsParms == mkOS(3, 1); /• DS parameter set (1) V 
eCfParms == mkOS(4, 1); /* CF parameter set (6) V 
eTim == mkOS(5, 1); I* Traffic Information Map (4:254) 7 
elbParms == mkOS(6, 1); r IBSS parameter set (2) 7 
eCtext == mkOS(16, 1); r challenge text (128, see 8.1.2.2) 7 
endnewtype ElementlD; 



Capability field bit assignments sort 



'7 



newtype Capability inherits Bitstring operators all; 
adding literals cEss t clbss, cPollable, cPoUReq, cPrivacy; 
axioms 

cEss == 38(1,0,0,0,0,0,0,0) // 0x00; /* ESS capability 7 
clbss == S8(0, 1 ,0,0,0,0,0,0) // 0x00; /* IBSS capability V 
cPollable == S8(0,0,1 ,0,0,0,0,0) // 0x00; r CF-pollable (sta), PC present (ap) V 
cPoUReq == S8(0,0,0, 1,0,0,0,0) // 0x00; f* not CF poll req (sta), PC polls (ap) V 
cPrivacy == S8(0,0,0,0, 1 ,0,0,0) // 0x00; /* WEP required */ 
endnewtype Capability; 



IBSS parameter set sort 

newtype IbssParms inherits Octetstring operators all; 
adding operators 

atimWin : IbssParms -> TU; 

setAtimWin : IbssParms, TU -> IbssParms; 
axioms 

for all ib in lbssParms( for all u in TU( 

atimWin(ib) == octetVal(ib(0)) + (octetVal(ib(1)) * 256); 
setAtimWin(ib, u) == mkOS(u mod 256, 1) // mkOS(u / 256, 1); )); 
endnewtype IbssParms; 
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[ ]\ I/ *** ** * N 

! v ] CF parameter set sort 

L I * — — — / 

newtype CfParms inherits Octetstring operators all; 
adding operators 
cfpCount : CfParms -> Integer; /* CfpCount field (1) 7 
setCfpCount : CfParms, Integer -> CfParms; 
cfpPeriod : CfParms -> Integer; r CfpPeriod field (1) 7 
setCfpPeriod : CfParms, Integer -> CfParms; 
cfpMaxDur : CfParms -> TU; /* CfpMaxDuration field (2) 7 
setCfpMaxDur : CfParms, TU -> CfParms; 
cfpDurRem : CfParms -> TU; /* CfpDurRemaining field (2) 7 
setCfpDurRem : CfParms, TU -> CfParms; 
axioms for all cf in CfParms( for all i in Integer^ for all u in TU( 
cfpCount(cf) == octetVal(cf(0)); 
setCfpCount(cf, i) == mkOS(i, 1) // Tail(cf); 
cfpPeriod(cf) == octetVal(cf(1)); 

setCfpPeriod(cf, i) == cf(0) // mkOS(i, 1) // SubStr(cf,2,4); 
cfpMaxDur(cf) == octetVal(cf(2)) + (octetVal(cf(3)) * 256); 
setCfpMaxDur(cf, u) == SubStr(cf, 0, 2) // mkOS(u mod 256, 1) 

// mkOS(u / 256, 1 ) // SubStr(cf, 4, 2); 
cfpDurRem(cf) == octetVal(cf(4)) + (octetVal(cf(5)) * 256); 
setCfpDurRem(cf, u) == SubStr(cf, 0, 4) // mkOS(u mod 256, 1) 

// mkOS(u / 256, 1); ))); 
endnewtype CfParms; 



operator 

AldLookup 



Sorts for association management at AP 



7 



synonym sMaxAld Integer = 2007; /* 2007 is largest allowable value 7 
r implementation limit may be lower 7 

syntype Asocld = Integer constants 0:sMaxAld endsyntype Asocld; 
I* Station Association Record - only used at APs */ 

newtype AsocData struct 

adAddr MacAddr; /* address of associated station */ 
adPsm PwrSave; /* power save mode of the station 7 
adCfPoll Boolean; /* true if station is CfPollable 7 
adPollRq Boolean; /* true if station requested polling 7 
adNoPoll Boolean; /* true if station requested no polling 7 
adMsdulP Boolean; /* true if partial Msdu outstanding to sta 7 
adAuth AuthType; /* authentication type used by station 7 
adRates RateSet; /* supported rates from association request 7 
ad Age Time; /* time of association 7 

endnewtype AsocData; 

r Association table - array of AsocData, only used at APs 7 

r index: = AldLookup(table, addr) 7 

V returns the index of location where table(x)!adAddr=addr 7 

r or 0 rf no such location found. 7 

newtype AldTable Array( Asocld, AsocData); 

adding operators 
AldLookup : AldTable, MacAddr -> Asocld; 

operator AldLookup; 
fpar tbl AldTable, val MacAddr; returns Asocld; referenced; 
endnewtype AldTable; 
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Operator AldLookup 



AldLookup_1a(1) 



| ; fpar i\ 
i tbt AldTable; ) 
! val MacAddr ; • 
J returns Asocld ; \ 



del k Asocld ; K 
del result Asocld; 
del tst AsocData 



Start search at 1. 
AldTable index 
range includes 0 
because Ald=0 
is a shorthand 
used to indicate 
buffered broadcast 
or multicast frames. 



k:= 1 



k:= k+1 




(false) 



else 



result:= k 




/* This is a procedural operator K 
for sort AldTable. ^ 
The association ID table is 
searchable by MacAddr using 

index:= AldLookup(table, addr) 
where table is an AldTable. 
This operator returns the 
first index value where the 
table entry is equal to addr, 
or 0 if no match found. 7 



(=sMaxAld) 



result:= 0 




result 
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3124_d\TIM(31) 



operator 

mkTim 



operator 

nextAld 



Traffic Information Map (TIM) support sorts 

/* TrafficMap is an Array of Bit indexed by Aid. */ 
/* Bits =1 in TrafficMap denote the presence of buffered frame(s) */ 
/* for the station assigned that Aid. TrafficMap operators are: 7 
/* mkTim(trafficMap, dtimCnt, dtimPer, lowAld, highAld, best) 7 
/* returns Octetstring to use as the info field of a TIM element */ 
/* The TIM will contain bits =1 for TrafficMap locations in the 7 
/* range (lowAld):(highAld). Buffered broadcasts and multicasts 7 
/* (Aid 0) are indicated if dtimCnt=0 and if bcst=true. 7 
/* nextAld(trafficMap, currentAld) 7 

/* returns index greater than currentAld at which TrafficMap=1 . 7 
r tf no locations before sMaxAld are =1, returns 0. */ 
newtype TrafficMap Array( Asocld, Bit); 
adding operators 
mkTim : TrafficMap, Integer, Integer, Asocld, Asocld, Boolean -> 
nextAld : TrafficMap, Asocld -> Asocld; 
operator mkTim; 
f par trf TrafficMap, dtc Integer, dtp Integer, xlo Asocld, 
xhi Asocld, be Boolean; returns Octetstring; referenced; 
operator nextAld; 
f par trf TrafficMap, x Asocld; returns Asocld; referenced; 
endnewtype TrafficMap; 

/* TIM is a subtype of Octetstring with operators: */ 
P bufFrame(tim,Ald) returns true if the TIM info field */ 
/* (obtained using getElem) is =1 at tim(Ald). 7 
/* bufBcst(tim) returns true if the TIM info field 7 
/* indicates buffered broadcast/multicast traffic 7 
/* dtCount(tim) returns DTIM count value from TIM 7 
/* dtPeriod(tim) returns DTIM period value from TIM 7 
newtype TIM inherits Octetstring operators all; 
adding operators 

bufFrame : TIM, Asocld -> Boolean; 

bufBcst : TIM -> Boolean; 

dtCount : TIM -> Integer; 

dtPeriod : TIM -> Integer; 
axioms 

for all el in TIM( for all a in Asocld( 
bufFrame(el, a) == 
if a < (octetVal(el(2) and OxFE) * 8) then false 
else 

if a >= ((octetVal(el(2) and 0xFE)*8) + ((Length<el)-3)*8)) 
then false 
else 

Extract!(B_S(el), (a-(octetVal(el(2) and 0xFE)*8)+24)) = 1 
fifi; 

bufBcst(el) == (el(2) and 0x01 ) = 0x01 ; 
dtCount(el) == octetVal(el(0)); 
dtPeriod(el) == octetVal(ei(1)); )); 
endnewtype TIM; 



Octetstring; 
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Operator mkTim 



MkTim_1a(1) 



; fpar i \ 

trf TrafficMap, * 

dtc Integer, 

dtp Integer, 

xlo Asocld, 

xhi Asocld, 

be Boolean ; 
returns Octetstring ; 



del i, j, k Asocld ;|\ 
del tim, tmp 
Octetstring ; 



Start TIM 
with DTIM 
count and 
period fields. 



c 




) 






tim:= 
mkOS(dtd)// 
mkOS(dtp,1) 








k:= 


xlo, 
xhi 





/* This procedural operator is part[\ 
of sort TrafficMap. mkTim builds 
the info field for a TIM element 
from the DTIM count and DTIM 
period values and the contents 
of the (xlo:xhi) range of bits in 
the TrafficMap. The resulting 
Octetstring can be used as an 
operand of mkElem (by an AP 
generating a Beacon frame). 7 



Search down from [ 
high limit (xhi) r 
for a non-zero ] 
traffic map bit. J 



Floor starting 
index to even 
multiple of 8. 



(false) 



(i / 16) * 2 



Add starting 
index to bc/mc 
indicator to 
get bitmap 
control field 
value for TIM. 





k:= k-1 



T 



| Search up from 
-i low limit (xlo) 
] for a non-zero 
j traffic map bit. 



(false) 



if((dtc=0) 
and be) and 



j:=i + 
if ((dtc=0) 
and be) and 



(trf(0)=1) 
then 1 
else 0 fi 



(trf(0)=1) 
then 1 
elseO fi 



tmp:= 
«type 
Octetstring » 



tmp:= 
«type 
Octetstring » 



mkString( 
mkOctetQ)), 
tim:= 
tim // tmp 




mkString( 
mkOctet(j)), 
tim:= tim // 
tmp // 01 



J If no 1s in the partial 
i bitmap, generate TIM 
Iwith index 0 and one 
[octet =0 (see 7.3.2.6). 



i:=i*8, 
k:= 

((k-i)/8) + 1 



Append octets • 
in active part ! 
of bitmap to I 
the TIM. j 



tim:= tim // 
0_S( «type 
Bitstring» 




S8(trf(i), 
trf(i+t), 
trf(i+2), 
trfti+3), 
trf(i+4), 
trf(i+5), 
trf(i+6), 
trf(i + 7)) ) 



j This method of calculating bitmap 
- 1 index and octet count meets alignment 
| and length restrictions implicit in 
| the encoding of the TIM bitmap control 
t field (7.3.2.6). However, if xlo is not a 
| multiple of 16, or xhi is not a multiple 
| of 8, bits outside the range (xlo:xhi) 
i will appear in the TIM element. This 
| may be of concern to implemented, but 
| is not a problem in the formal description 
i because criteria for selecting bitmap 
\ subsets are not part of this standard. 
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Operator nextAld 



NextAld_1a(1) 



; fpar i \ 

trf TrafficMap', ) 
x Asocld ; i 

returns Asocld ;l 



del k, result Asocld 




k:= 


= X 






) 


k:= k+1 



This procedural operator \ 
is part of sort TrafficMap. 
nextAld searches upward 
from the specified initial 
index (x) in a TrafficMap 
and returns the index of 
the first bit =1. If the end 
of the TrafficMap (index= 
sMaxAld) is reached with 
no 1s found, a vatue of 0 
is returned. */ 




(true) 



result:= k 



result:= 0 




result 
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o 

Package macsorts 3125_d\RateAndDurationSorts(31) 



, K 

, " Multi-rate support sorts 

i ; 

newtype Rate inherits Octet operators all; 
adding operators 

calcDur : Rate, Integer -> Integer; /* converts (rate.bitCount) to integer usee 7 
rateVal : Rate -> Rate; T clears high-order bit V 
basicRate : Rate -> Rate; /* sets high-order bit V 
isBasic : Rate -> Boolean; /* true if high-order bit set V 
axioms 

for all r in Rate( for all i in lnteger( for all b in Boolean( 
calcDur(r, i) == ((((10000000 + (octetVal(r and 0x7F) - 1)) / 

(500 * octetVal(r and 0x7F))) * i) + 9999) / 10000; 
rateVal(r) == r and 0x7F; basicRate(r) == r or 0x80; 
isBasic(r) == (r and 0x80) = 0x80; ))); 
endnewtype Rate; 

syntype RateString = Octetstring endsyntype RateString; 



MPDU duration factor support sort 

/* These operators support the encoding used to allow 7 

/* an Integer to represent the value of aMpduDurationFactor. */ 

/* calcDF(PlcpBits, MpduBits) returns an Integer which is */ 

/* the fractional part of ((PlcpBits/MpduBits)-1)*(1e9). V 

/* stuff(durFactor, MpduBits) returns the number of PIcpBits */ 

/* which result from MpduBits at the specified durFactor. V 

newtype DurFactor inherits Integer operators alt; 

adding operators 
calcDF : Integer, Integer -> DurFactor; 
stuff : DurFactor, Integer -> Integer 

axioms 

for all df in DurFactor( for all mb, pb in lnteger( 

calcDF(pb, mb) == ((pb * 1000000000) / mb) - 1000000000; 
stuff(df, mb) == ((mb * df) + (mb - 1)) / 1000000000; )); 
endnewtype DurFactor; 
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FH parameter set sort 



newtype FhParms inherits Octetstring operators all; 
adding operators 

dwellTime : FhParms -> TU; /* Dwell Time field (2) 7 

setDwellTime : FhParms, TU -> FhParms; 

hopSet : FhParms -> Integer; r Hop Set field (1) 7 

setHopSet : FhParms, Integer -> FhParms; 

hopPattern : FhParms -> Integer; T Hop Pattern field (1) 7 

setHopPattem : FhParms, Integer •> FhParms; 

hoplndex : FhParms -> Integer; /* Hop Index field (1) */ 

setHoplndex : FhParms, Integer -> FhParms; 
axioms 

for all fh in FhParms( for all i in lnteger( for all u in TU( 
dwellTime(fh) == octetVal{fh(0)) + (octetVal(fh(1)) * 256); 

setDwellTime(fh, u) == mkOS(u mod 256, 1) // mkOS(u / 256, 1) // SubStr(fh t 2, 3); 
hopSet(fh) == octetVal(fh<2)); 

setHopSet(fh.i) == SubStr(fh,0,2) // mkOS(i,1) // SubStr(fh,3,2); 
hopPattem(fh) == octetVal(fh(3)); 

setHopPattem (fh, i) == SubStr(fh,0,3) // mkOS(i,1) // Last(fh); 
hoplndex(fh) == octetVal(fh(4)); 
setHoplndex(fh, i) == SubStr(fh, 0, 4) // mkOS(i, 1);))); 
endnewtype FhParms; 



I************************ ***** 

DS parameter set sort 
**** **************** 



7 

newtype DsParms inherits Octetstring operators all; 

adding operators 
curChannel : DsParms -> Integer; f* Current Channel (1) *j 
setCurChannel : DsParms, Integer -> DsParms; 

axioms 

for all ds in DsParms( for all i in Integer^ 
curChannel(ds) == octetVal(ds(0)); 
setCurChannel(ds, i) == mkOS(i); )); 
endnewtype DsParms; 
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3127_d\PHY_Params(31) 



Generic PHY parameter set sort 



/* Generic PHY parameter element for signals related to Beacons 7 
/* and Probe Responses that are PHY-type independent. 7 
syntype PhyParms = Octetstring endsyntype PhyParms; 



NEWTYPE PhyChrstcs struct K 

aSlotTime Usee; 

aSifsTime Usee; 

aCCATime Usee; 

aRxTxTumaroundTime Usee; 

aTxPLCPDelay Usee; " 

aRxPLCPDelay Usee; 

aRxTxSwitchTime Usee; 

aTxRampOnTime Usee; 

aTxRampOffTime Usee; 

aTxRFDelay Usee; 

aRxRFDelay Usee; 

aAirPropagationTime Usee; 

aMACProcessingDelay Usee; 

aPreambteLength Usee; 

aPLCPHeaderLength Usee; 

aMPDUDurationFactor DurFactor; 

aMPDUMaxLength Integer; 

aCWmin Integer; 

aCWmax Integer; 
EndNewType PhyChrstcs; 
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use macsorts 



Package macmib 



/* This Package contains definitions of the MAC MIB attributes K 
and the subset of the PHY MIB attributes used by the MAC state u 
machines. These are needed under Z.100 to permit analysis of 
the state machine definitions. In future revisions these may 
be replaced with the ASN.1 MIB definition which appears as 
as Annex D, for use with a Z.105-compliant SDL tool is available. V 



3201_d\StationConfig(5) 



StationConfig Table 



remote dot 11 MediumOccupancyLimit TU nodelay; 

synonym dotUCfPollable Boolean = «package macsorts» sCfPollable; 

remote dot1 1 CfpPeriod Integer nodelay; 

remote dot11CfpMaxDuration TU nodelay; 

remote dotHAuthenticationResponseTimeout TU nodelay; 

synonym dot11PrivacyOptionlmplemented Boolean=true; 

remote dotHPowerMangementMode PwrSave nodelay; 

remote dotHDesiredSsid OctetString nodelay; 

remote dot1 1 Desired BssType BssType nodelay; 

remote dotHOperationalRateSet RateString nodelay; 

remote dotHBeaconPeriod TU nodelay; 

remote dot1 1 DtimPeriod Integer nodelay; 

remote dotHAssociationResponseTimeout TU nodelay; 

remote dotHWepUndecryptableCount Counter32 nodelay; 

remote dotHReceiveDTIMs Boolean nodelay; 

remote dotHAuthenticationType AuthTypeSet nodelay; 



AuthenticationAlgorithms Table 



7 



synonym dot 11 Authentication Algorithms AuthTypeSet = 
incl(open_system, incl(shared_key)); 
T NOTE: The members of this set are the 
dotHAuthenticationAlgorithm values of all 
dot1 1 AuthenticationAlgorithmsEntry instances 
for which dot1 1 AuthenticationAlgorithmsEnable=True. 
Do not include shared_key in this set 
unless dot11PrivacyOptionlmplemented=true. */ 



WepDefaultKeys Table 

(if dot1 1 PrivacyOptionlmplemented=tfue) 



remote dot1 1 WepDefaultKeys Key Vector nodelay; 



WepKeyMappings Table 

(if dot1 1 PrivacyOptionlmplemented=tnje) 



remote dot11 WepKeyMappings KeyMapArray nodelay; 
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Privacy Table 

(only if dot11PrivacyOptionlmplemented=true) 



remote dot11 Privacy Invoked Boolean nodelay; 
remote dotHWepDefaultKeyld Keylndex nodefay; 
synonym dotHWepKeyMappingLength Integer = 

«package macsorts» sWepKeyMappingLength; 
remote dotHExcludeUnencrypted Boolean nodelay; 
remote dotHWeplcvErrorCount Counter32 nodelay; 
remote dotHWepExcludedCount Counter32 nodelay; 



Operation Table 



synonym dotHMacAddress MacAddr = 
«type MacAddr» S6(0x00. 0x1 1, 0x22, 0x33, 0x44, 0x55); 
/* each station has a unique globally administered address V 
/* Value may be overwritten with locally administered address at 7 
/* MlmeReset, but is always a static value during MAC operation */ 

remote dot1 1 RtsThreshold Integer nodelay; 

remote dot1lShortRetry Limit Integer nodelay; 

remote dotHLongRetryLimit Integer nodelay; 

remote dotHFragmentationThreshold Integer nodelay; 

remote dotHMaxTransmitMsduLifetime TU nodelay; 

remote dotHMaxReceiveLifetime TU nodelay; 

synonym dot11 Manufacturers Charstring = 'name of manufacturer*; 

synonym dotHProductld Charstring = 'identifier unique to manufacturer'; 



"******************************•**** »' 



GroupAddresses Table 



remote dot 11 GroupAddresses MacAddrSet nodelay; 
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Package macmib 3203_d\Counters(5) 



Counters Table 

remote dotHTransmittedFragmentCount Counter32 nodelay; 
remote dot11MulticastTransmittedFrameCount Counter32 nodelay; 
remote dotHFailedCount Counter32 nodelay; 
remote dot1 1 RetryCount Counter32 nodelay; 
remote dotHMultipleRetryCount Counter32 nodelay; 
remote dot1 1 RtsSuccessCount Counter32 nodelay; 
remote dotHRtsFailureCount Counter32 nodelay; 
remote dotHAckFailureCount Counter32 nodelay; 
remote dotHReceivedFragmentCount Counter32 nodelay; 
remote dot11MulticastReceivedFrameCount Counter32 nodelay; 
remote dotUFcsErrorCount Counter32 nodelay; 
remote dotHFrameDuplicateCount Counter32 nodelay; 
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use macsorts 



Package macmib 3204_d\PhyOperation(5) 



PhyOperation Table 
(values shown are mostly for FH PHY) 

ft********************************************************* *********y 

synonym FHphy Integer = 01; r enumerated dotHPHYType value 7 
synonym DSphy Integer = 02; V enumerated dotHPHYType value V 
synonym IRPhy Integer = 03; I* enumerated dotHPHYType value 7 
synonym dotHPHYType Integer = FHphy; 
remote dot1 ICurrentRegDomain Integer nodelay; 
synonym dotHTempType Integer = 01; 

* PhyCharacteristic Parameters (values shown are mostly for FH PHY ) 
„ *** * ... . * — ; 

/* NOTE: The PhyCharacteristics are defined as synonyms because 
their values are static during MAC operation. It is assumed 
that , during each initialization of MAC operation, current 
values for each of these parameters are obtained from the 
PHY using the PlmeCharacteristics primitive. V 

synonym aSlotTime Usee = (aCcaTime + aRxTxTumaroundTime + 
aAirPropagationTime + aMacProcessingTime); 

synonym aCcaTime Usee = 27; 

synonym aRxTxTumaroundTime Usee = (aTxPlcpDelay + aRxTxSwitchTime + 

aTxRampOnTime + aTxRfDelay); 
synonym aTxPlcpDelay Usee = 1 ; 
synonym aRxTxSwitchTime Usee = 10; 
synonym aTxRampOnTime Usee = 8; 
synonym aTxRfDelay Usee = 1; 

synonym aSifsTime Usee = (aRxRfDelay + aRxPlcpDelay + 

aMacProcessingTime + aRxTxTumaroundTime); 
synonym aRxRfDelay Usee = 4; 
synonym aRxPlcpDefay Usee = 2; 
synonym aMacProcessingTime Usee = 2; 
synonym aTxRampOffTime Usee = 8; 
synonym aPreambleLength Usee = 96; 
synonym aPlcpHeaderLength Usee = 32; 

synonym aMpduDurationFactor «package macsorts>> DurFactor = 31250000; 
synonym aMpduMaxLength Integer = 4095; 
synonym aAirPropagationTime Usee = 1; 
synonym aCWmax Integer = 1023; 
synonym aCWmin Integer =15; 
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use macsorts ; 



Package macmib 



3205_d\PhyRateFhss(5) 



SupportedDataRatesTx Table (values shown are for FH PHY) ^ 
synonym aSupportedRatesTx Octetstring = S8(0x82, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00); 



********************* 



SupportedDataRatesFU Table (values shown are for FH PHY) 



synonym aSupportedRatesRx Octetstring = S8(0x82, 0x04, 0x00,0x00, 0x00, 0x00, 0x00, 0x00); 
synonym aPrefMaxMpduFragmentLength Integer = aMpduMaxLength; 



PhyFHSS Table 



(only used with FH PHY) 



********************* 



synonym dotHHopTime Usee = 224; 

remote dotHCurrentChannelNumber Integer nodelay; 

synonym dotHMaxDwellTime TU = 390; 

remote dot1 1 CurrentSet Integer nodelay; 

remote dot1 1 CurrentPattern Integer nodelay; 

remote dotHCurrentlndex Integer nodelay; 



*********** ******************* *************** * , 



/ 

/* The MAC state machines currently do not reference any attributes in: 
PhyAntenna Table, PhyTxPower Table, PhyDsss Table, Phylr Table, 
RegDomainsSupported Table, AntennasList Table. */ 

/*endpackage;7 
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C.3 State machines for MAC stations 

The following SDL-92 system specification defines operation of the MAC protocol at an IEEE 802. 1 1 STA. 
Many aspects of STA operation also apply to AP operation. These are defined in blocks and processes refer- 
enced from both the STA and AP system specifications. Blocks and processes used in both STA and AP are 
identifiable by the SDL comment /* for STA & AP */ below the block or process name. Blocks and pro- 
cesses specific to STA operation are identifiable by the SDL comment /* station version */ below the block 
or process name. The definitions of all blocks and processes referenced in the station system specification 
appear in Clause C.3. 

The remainder of Clause C.3 is the formal description, in SDL/GR, of an IEEE 802. 1 1 STA. 
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use macsorts ; 
use macmib : 



3 



System Station 



Includes request ' 
validation and (. . 
add/remove ' 
MAC headers. | 



MaUnitdata. indication. | 
MaUnitdataStatus.indication 

MAC_SAP 

Mallnitdata.requestJ 



MAC_Data_ 
.Service 

/* for STA & AP V 



(MlmeConfirm Signals). I 
(MlmelndicationSignals) 

SM_MLME_SAP 



^(MlmeRequestS ignals)j 



Station, 1b(3) 



MAC_Management_ 
.Service 

r for STA & AP */ 



' Includes MAC MIB, 
MIB access, and 
' filtering of Mime 
| request and confirm. 



Msdulndicate 



Includes encryption, 1 
fragmentation, and ]- - 
power save queuing, i 



Includes DCF, 
Rts/Cts, Ack & 
CF-Ack, retries. 
CF-poll response. 
Atim handling, 
and PS-Poll. 



[BkOone. 
TxConfirm 



TX 



j^MsduConfirmJ 



RSDU 



TSDU 

MsduRequestJ 



MPDU_Generation_ 
_STA 

/* station version */ 



MmRequest. 
PsChange. 
Ps Response 



AtimW, 

PduConfirm. 

CfPolled 



TPDU 



jVduRequestJ 



MMTX 



[MmConfirm,! 
Pslnquiry 



MCTL 



ProtocoLControL 
_STA 

/'station version*/ 



^{PlmeConfirmSignals) 



Backoff, 
Cancel, 
TxRequest 



Transmission 
/for STA & AP7 



Busy. 

Idle, 

Slot 



^{PhyTxConfirmSignalsjJ 



PRYJSAFITX 

(PhyTxRequestSignals)J 



7K 



(MmgtConfirmSignals), 
(MmgtlndicationSignals] 



MMGT 



^(MmgtRequestSignals)J 



MLME_STA 
/'station version*/ 



Ooze, 






MmCancel, 




Mmlndicate. 


SsResponse. 




PsmDone, 


SwChnl, 




Ss Inquiry. 


Tbtt, Wake 




SwDone 



^Pslndicatej 



Rxlndicate, 
Need Ack. 
RxCfAck, 
RxCfPoll 



CS 



MLME_PLME_SAP 



^ChangeNavJ 



i Includes scan. join. 
— .J beacon/dwell and 
> awake/doze timing, 
|(re/dis)associate, 
i (de)authenticate, 
! start IBSS. and 
i monitor of station 
, & power save state. 



PS 



^ChangeNavJ 



Reception 
/*for STA & AP*/ 



^(PhyRxSignals)] 



i Includes validate, decrypt, 
- - \ address & duplicate filter, 
i defragment, channel state 
j (physical and virtual carrier 
, sense), and IFS & slot timing. 



^(PlmeRequestSignals)J 



"PHTJSAPrRX 

PhyCcareset. requestj 



•Includes backoff 
■ -| FCS generate, and 
itimestamp insert 
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use macsorts 
use macmib : 



System Station 



Sta_signals_2d(3) 



signal K 
AtimW, ^ 
Backoff (Integer. Integer), 
BkDone(lnteger). 
Busy. 
Cancel, 
CfPolled, 

ChangeNav(Time.Duration.NavSrc). 

Ooze. 

Idle, 

MaUnitdata.indicationfMacAddr.MacAddr. 

Rou ting, Oct etstring.RxStatus, 

Cf Priority. ServiceClass). 
MaUnitdata.request(MacAddr,MacAddr. 

R ou ting. Oct etstring.CfPriority, ServiceClass). 
MaUnitdata Status. indication(MacAddr. 

MacAddr.TxStatus.CfPriority, ServiceClass), 
MlmeAssociate.confirm(MlmeStatus), 
M I meAssociat e. indication (Mac Ad dr). 
MlmeAssoctate.request(MacAddr,Kusec.Capability.lnteger), 
M I meAuthenticate. confirm 

(MacAddr.AuthType.MlmeStatus). 
MImeAuthenticate. indication (MacAddr.Auth Type). 
MlmeAuthenticate.request(MacAddr.AuthType.Kusec). 
MlmeDeauthenticate.confirm(MacAddr.MlmeStatus), 
MlmeDeauthenticate.indication(MacAddr.ReasonCode), 
MlmeDeauthenticate.request(MacAddr,ReasonCode), 
MlmeDisassociate.confirm(MlmeStatus), 
MlmeDis associate, indication (MacAddr.ReasonCode), 
MlmeDisassociate.request(MacAddr.ReasonCode). 
MlmeGet.confirm(MibStatus.MibAtrib,Mib Value), 
MlmeGet.request(MibAtrib), 
Mime Join. confirm (Mime Status), 
MlmeJoin.request(BssDscr. Integer, Usee, Rat estring), 
MlmePowermgt.confirm(MlmeStatus), 
Ml me Powermgt. request (PwrSave. Boolean, Boolean). 
MlmeReassociate.confirm(MlmeStatus), 
MlmeReassociate.indication(MacAddr), 
MlmGReassociate.request(WacAddr T Kusec, Capability. Integer) 
MlmeReset.confirm(MlmeStatus), 
MlmeReset.requBst(MacAddr. Boolean), 
MlmeScan.conftrm(BssDscrSet.MlmeStatus), 
MlmeScan.request(BssTypeSet,MacAddr.Octetstring, 

Scan Type. Usec.lntstring.Kusec.Kusec), 
MlmeSet.confirm(MibStatus,MibAtrib), 
MlmeSet.request(MibAtrib.MibValue). 
MlmeStartconfirm(MlmeStatus), 
MlmeStart.request(Octetstring,BssType,Kusec. 

Integer.CfParms.PhyParms.lbssParms.Usec. 

Capabiiity.Ratestring.Ratestring) ; 



signal K 
MmCancel, *A 
MmConfirm(Frame.TxStatus). 
Mmlndicate(Frame. Time, Time.State Err). 
MmRequest(Frame.lmed.Rate). 
MsduConftrm(Frame.CfPriority.TxStatus). 
Msdulndicate(Frame.CfPriority). 
MsduRequest(Frame.CfPriority). 
NeedAck(MacAddr.Tirne.Duration.Rate), 
PduConfirm(F rag Sdu.Tx Result), 
PduRequest(FragSdu), 
PhyCca.indication(Ccastatus), 
PhyCcarst. confi rm, 
PhyCcarst. request. 
Phy Data, confirm. 
PhyData.indication(Octet), 
Phy Data, re quest (Octet). 
PhyRxEnd.indication(PhyRxStat), 
PhyRxStart.indication(lnteger,Rate). 
PhyTx End. confirm, 
PhyTxEnd. request. 
P hyTx Start . co nfi rm , 
PhyTxStart.request{lnteger.Rate), 
PlmeCharacteristics.confirm(PhyChrstcs). 
PlmeCharact eristics, request 
PlmeGet.confirm(MibStatus. 

tVIibAtrib.MibVaiue). 
PlmeGet.request(MibAtrib). 
PfmeReset.confirm(Bootean). 
PlmeReset. request. 
PlmeSetconfirm(MibStatus.MibAtrib), 
PlmeSet.request(MibAtrib.MibValue), 
PsmDone, 

PsChange(MacAddr.PsMode). 

Pslndicate(MacAddr.PsMode), 

Pslnquiry(MacAddr), 

PsResponse(MacAddr.PsMode), 

Reset MAC. 

RxCfAck(MacAddr), 

Rxlndicate(Frame,Time.Time.Rate). 

Slot. 

Sslnquiry(MacAddr),- 
SsR es pons e( Mac Add r, 

Stat ion State, Station State), 
SwChnl(lnteger. Boolean), 
SwOone, 
TBTT, 
TxConfirm, 

Tx Request (Frame, Rate), 
Wake ; 



326 



Copyright © 1999 IEEE. All rights reserved. 



ISO/IEC 8802-11: 1999 (E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE 802.1 1, 1999 Edition 



use macsorts 
use macmib ; 




System Station Sta.signallists.3c(3) 



i 



signaltist K 
MlmeRequestSignats= ^ 
MlmeAssociate.request 
Mime Authenticate, request. 
MlmeDeauthenticate. request, 
Ml me Disassociate .re quest, 
MlmeGet. request. 
M I meJoin. request, 
MlmePowermgt.request, 
MlmeReassociate.request, 
MlmeReset.request, 
MlmeScan. request. 
MlmeSet. request, 
MlmeStart. request ; 



signaltist K 
MlmeConfirmSignals= ^ 
MtmeAssociate. confirm, 
MlmeAuthenticate.confirm, 
MlmeDeauthenticate. confirm, 
MlmeDisassociate. confirm. 
MlmeGet.confirm. 
MlmeJoin.confirm. 
MlmePowermgt.confirm, 
MlmeReassociate. confirm, 
MlmeReset.confirm. 
MlmeScan.confirm. 
M I meSet. confirm, 
Ml me Start, confirm ; 



signaltist K 
MlmelndicationStgnals= ^ 

MimeAuthenticate. indication. 

MlmeDeauthenticate. indication, 

MlmeDisassociate. indication. 

MlmeAssociate.indication. 

MlmeReassociate. indication : 



signaltist N 
MmgtRequestSignals= L_ 

MlmeAssociate.request. 

MlmeAuthenticate.request, 

MlmeDeauthenticate. request, 

MlmeOisassoaats. request. 

M I meJoin. request. 

MlmePowermgt.request. 

MlmeReassociate.request, 

MlmeScan. request. 

MimeStart. request ; 



signallist N 

MmgtConfirmSignals= 
MlmeAssociate.conftrm, 
MlmeAuthenticate.confirm, 
MlmeDeauthenticate. confirm, 
MlmeDisassociate. confirm, 
MlmeJoin.confirm, 
M I m ePowe rmgt .confirm , 
MlmeReassociate.confirm, 
MlmeScan.confirm, 
MlmeStart. confirm ; 



signallist K 
MmgtlndicationSignals= L - 
MimeAuthenticate. indication, 
MlmeDeauthenticate. indication. 
MlmeDisassociate.indication, 
MlmeAssociate.indication. 
MlmeReassociate.indication ; 



signaltist 

PhyTxRequestSign; 
PhyTxStart. re quest. 
PhyTxEnd. request, 
PhyData. request ; 



signallist \ 
PhyTxConftrmSig nats^r 

PhyTxStart. confirm. 

PhyTxEnd. confirm. 

PhyOata.confirm ; 



signallist 

PhyRxStgnals= 
PhyRxStart. indication. 
PhyRxEnd.indication, 
PhyData. indication. 
PhyCca. indication, 
PhyCcareset. confirm ; 



signallist [\ 
PlmeRequestSignals= L 

PlmeCharacteristics. request, 

PI meGet. request. 

PI meS at. request, 

PlmeReset. request 



signallist N 
PlmeConfirmSignals= ^ 

PlmeC ha ra cteristi cs . co nfi rm, 

PlmeGet.confirm, 

PlmeReset.confirm, 

PlmeSet.confirm; 
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MAC.SAP 



Block MAC_Data_ Service 



MaUnildata._ 
indication 



[*MaUnitdataStatus._ 
indication 



Mac_Data_1a(1) 



I* This block provides [\ 
the MAC.SAP functions? 
described in Clause 6, 
conveying MSDUs from 
and to the LLC entity. 
This block operates 
identically in STA 
and AP, but in STA 
the TSDU signal route 
connects directly to 
MPDU_Generation. and 
the RSDU signal route 
connects directly 
from ProtocoLControl, 
whereas in AP both of 
these signal routes 
connect to Distribution 
Service. V 



ToLLC 



FromLLC 



MSDU_to_LLC 
(1.1) 



MaUnitdata.request I 



MSDU.from LLC 
(1.1) 



1 



Msdulndicate 



1 



MsduConfirmj 



RxMsdu 



TxMsdu 



RSOU 



JfylsduRequestj 



TSDU 
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Process MSDUJo_LLC 



Msdu_to_LLC_1a(1) 



/* This process runs when j\ 
reception is successfully ^ 
completed on an MSDU 
addressed to the local 
LLC entity. This process 
extracts the appropriate 
address and status info, 
removes the MAC header 
from the MSDU data fteid 
(the FCSand tV/ICV are 
removed much earlier in 
reception handling), and 
generates the indication 
to LLC. Reception status 
is always "successful* 
because a receive error 
causes the MSDU to be 
discarded before reaching 
MAC Data Service. */ 



To_LLC 



Msdulndicate^ 
(sdu. cf) 



del cf CfPriority : 
del LLCdata Octetstri™ 
del sa. da MacAddr : 
del sdu Frame ; 
del srv ServiceClass 



j From source of the RSDU channel. 
- ST A source is Protocol Control, 
i AP source is Distribution Service. 



da:= addM(sdu) 



sa:= if frDs(sdu)=1 
then addr3(sdu) 
else addr2(sdu) fi 



srv:= 
if orderBtt(sdu)=1 
then stricllyOrdered 
else reorderable fi 



Remove MAC header 1 | 

from beginning of j. , LLCdata:= substr 

MSDU to obtain the ' (sdu. sMacHdrLng, 

LLC data octet string. ] length(sdu) - 
1J sMacHdrLng) 



Reception status 
always successful 
because any error 
would prevent the 
Msdulndicate 
from reaching 
this process. 



<MaUnitdata._ 
indication(sa, da, 
nulLrt. LLCdata, 
rx_success.cf.srv) 
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Process MSDU_from„LLC 



Msdu_from_LLC_1b(t) 



From.LLC 



del cf CfPriority : 
del LLCdata Octetstrini 
del rt Routing ; 
del sa. da MacAddr ; 
del sdu Frame : 
del srv ServiceClass ; 
del stat TxStatus : 



\ MaUnit_ 

^data._ 
/ request 




(sa. da. rt. 
LLCdata. 
cf. srv) 


successful. 
retryLtmit. 
txLifetime. 
or noBss 








'validate 
parameters'. 
stat= 




if rt /= null_rt then 
nonNullSourceRouting 

else if (length(LLCdata) 
> sMsduMaxLng) or 
(length(LLCdata) < 0) 
then excessiveDataLength 

else successful fi fi 


^^stat=^^ 
<L successful :> 



(falser 



(true) 



MsduConfirm / 


(sdu. srv. 




stat) 


\ 






srv 


= if 


orderBit 


(sdu) = 1 






da: 


= if 


toDs(sdu) = 1 



(reorderable) 





else 


stat:= 




unsupported. 




ServiceClass 





stat:= 
unavailable. 
ServiceClass 





(true) 


stat= 




noBss 






MaUnit. 

dataStatus.. 

indication 



stat:= 
unsupported. 
Priority 




(contention) 



(contentionFree) 



MaUnit_ 

dataStatus.. 

indication 



(sa, da, 
stat 
cf, srv) 




(true) 



MaUnit_ 

dataStatus.. 

indication 



(sa. da, 
unavailable. 
Priority, cf, srv) 




i If no PCF, 
— .[inform LLC. 

• send Msdu in 
J in contention 

• period. 2nd 
|MaUnitdata_ 

• Status reports 
| Tx result 



imported mAssoc. K 
mDisable. mlbss. ^ 
mPcAvail Boolean : 

imported 

dot1 1 PowenVtanagementMode PwrSave 
imported 
mBssId MacAddr : 



then 

strictlyOrdered 
else reorderable fi 



then addr3(sdu) 
else addrl(sdu) 
fi 



(addr2(sdu), 
da. stat. 
cf. srv) 




/* This process runs when N 
an MSDU to transmit is ^ 
presented by LLC. This 
process validates request 
parameters, and if valid 
attaches a basic MAC 
header and sends the MSDU 
to MPDU preparation (at 
STA) or to Distribution 
Service (at AP). If request 
is invalid, or when status 
is available for the valid 
Tx attempt, LLC is informed 
by an MaUnitdataStatus._ 
Indication generated by 
this process. 7 



Build frame with 24- octet 
MAC header and LLCdata: 

ftype:= data 

toDS := 0 

addr1:= da 

addr2:= dot1 1 MacAddress 
(sa parameter not used) - 
addr3:= m&ssld 
<other header fields> := 0 



dot1 1 MacAddress, 

import(mBssld), 

LLCdata) 



strictly^ 
Ordered) 



MsduRequest \^ 
(sdu, cf) y 



Send Msdu to 
-~ \ Mpdu preparation 
(to distribution 
service at AP) 
with basic header. 
Other fields are 
filled in prior 
to transmission. 
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TSDU 



Block MPDU_Generation_STA 



1 



signal 

FragConfirm(FragSdu.TxResul 
FragRequest(FragSdu) : 



Msdu Confirm 



Msdu 



sta_Mpdu_gen_1a(1) 



Includes encryption if 

do(1 1 PrivacyOption Implemented 

=lrue. This is a typical 

location, but impfementers 

may use other locations 

between the MAC_SAP 

and PHY_SAP_TX as 

long as they provide 

the specified behavior 

as observed at LLC, 

MLME and the WM. 



MsduRequest 



Prepare.MPDU 
(1.1) 



I* This block converts 
outgoing Msdus and Mmpdu: 
into Mpdus. fragmenting 
and encrypting as necessary. 
If the station is in a Bss, 
outgoing Msdus are directed 
via distribution service 
at the AP. 



The PM_Filter process queues 
frames needing announcement 
by Atim in an I bss; or frames 
to be sent in the CF- period 
at a CF-pollable station in 
a Bss. V 




MM_ 
TX 



^Pslnquiryj 



PM_Fiiter_STA 
0.1) 

P station version V 



[PsResponse.1 
PsChange 



AtimW, 

PduConfirm, 

CfPolled 



. Mpdu 



JpduRequestj 



TPOU 
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Process Prepare_MPDU 



prepare. 1 b(2) 




1 Procedure used for WEP encryption. 
■--J If dot1 1PrivacyOpttonlmplemented= 
i false, this procedure is not present. 



No_Bss 



imported mAssoc. mlbss. dotnPrivacylnvoked Boolean; K 

imported dot 11 FragmentationThreshold Integer: 

imported dot1 1 WepDefaultKeys Key Vector : 

imported dot11WepOefaultKeyld Keyfndex : 

imported dot1 IWepKeyMappings KeyMapArray : 

imported dot1 1 WepKeyMappingLength KeyMapArray Length 

imported mCap Octetstring ; 



del bemc. keyOk. 

useWep Boolean- fals 
del f FragNum : 
del fsdu FragSdu : 
del mpduOvhd, p. 

pduSize. thld Integer 
del pri Cf Priority : 
del rrsl TxResult : 
del sdu. rsdu Frame : 



< import \ 
(mAssoc) ? 



A. 



and (not 

import(mAct_ 

tngAsAp)) 



/ Prepare. \ 



■ All data frames 
■ \ in Bss sent to 
idistrib. service 



< 



not import \ 
(mAssoc) ? 



Msdu_ 
Request 
(sdu. pri) 



No.Bss 



sdu:= 
setAddrl 
(sdu, import 
(mBssId)). 

sdu:= 
setToDs 
(sdu.1) 



sdu:= 
setAddr3(sdu, 
addrl(sdu)). 



Invoked) and 
dot1 1 Privacy, 
Option_ 
Implemented 



useWep:= 
import( 
dot1 1 Privacy, 



Fragment and j 
encrypt is 
on next page. 




/" This process generates N 
one or more Mpdus from ^ 
each outgoing Msdu or 
Mmpdu. If encryption is 
needed, the Mpdus are 
encrypted before being 
passed to be filtered for 
possible power save or 
CF queuing before tx. V 



< import \ 
(mlbss) ? 



< import 
(mAding_ 
AsAp) 



> 



Prepare. 
_lbss 



' All data frames 
— j in Ibss sent to 
i destination sta. 



Msdu_ 
Request 
(sdu. pri) 



Prepare. 
AP 



Msdu. 

Request 

(sdu.pri) 



< 



not import \ 
(mlbss) ? 



1_ 



No.Bss 



MsduConfirrr 
(sdu.pri. 
no Bss) 



\1/ 



No.Bss 



Msdu_ 

Request 

(sdu.pri) 



not import v 
(mActing_ j> 
AsAp) / 



A. 



No.Bss 



■M mpdus sent 
-j even when not 
tin Bss/lbss. 



ResetMAC 



Mm. 

Request 

(sdu.pri) 



Frag_ 
Confirm 
(fsdu. pri. rrsl) 



Data frames 
rejected if 
no Bss/lbss. 
Implementations 
may retain these 
frames until a 
Bss becomes 
(re)available. 




1 (manage ment) 



wepBit=true in 
request for 3rd 
frame of shared 
key auth. seq. 



Confirm Msdu to i 
MAC data service, j. 
confirm Mmpdu to • 
MLME sub-block. 
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Process Prepare. MPDU 



fragment_2b{2) 



Initialize 
FragSdu 
structure 




fsdu!eol:=0. fsdu!sqf:=0. 
fsdu!src:=0. fsdu!lrc:=0. 
fsdu!psm:=false. 
fsdu!txrate:=0 




fsdu!grpa:= 

isGrp( 
addrl(sdu)). 



fsdu!cf:=pri, 

fsdu!cnfTo:=sender, 

fsdu!resume:=false 



dot1 1 Fragmen_ 
tationThreshotd 
must not be 
> dot11Max_ 
MpduLength. 











mpduOvhd:= 
sMacHdttng + 
sCrcLng 


* Iv and lev fields 
— -| not counted in pre- 
i fragment overhead. 










pduSize:= 
import 




(dot1 1 Fragment, 
ati on Threshold) 



(false) 



pduSize:= 
length(sdu) - 
sMacHdrLng 




pduSize:= 
pduSize - 
mpduOvhd 



i This is the typical 
- -J case, with the length 
i of all but the last 
\ fragment equal to 
' dot1 1 Fragmentation. 
| Threshold (plus 
i sWepAddLng if 
| useWep=true). The 
■ value selected for 
| pduSize must be 
">=256, even, and 
| <=aMpduMaxLength. 



fsdu!fTot:= 
((length(sdu) - 
sMacHdrtng) / 



pduSize) + 

if ((length(sdu) 
sMacHdilng) 
mod pduSize) 
/=0 

then 1 

else 0 fi 



fsdu!fTo1:= 





fsdu!pdus(0:= 

null. 
keyOk:=false 



fsdu!pdus(f):= 
fsdulpdus(f) // 
substr(sdu.O. 



fsdu!pdus(f):= 

setFrag( 
fsdu!pdus{f),f) 



fsdu!pdus(f):= 
setMoreFrag( 
fsdu!pdus(f).1) 



Encrypt 
(fsdu!pdus(f), 
keyOk. 





sMacHdrLng) // 
substr(sdu,p, 
pduSize) 



(false) 



(false) 



import(dot1 1 WepKey_ 
Mappings), 

import(dot1 1WepKey_ 
Mapping Length), 
tmport(dot1 1 Wep_ 
DefauttKeys), 
import{dot1 1 WepOefault_ 
Keyid), import(mCap)) 



pduSize:= if 

(p+pduSize) > length(sdu) 
then (length(sdu) - p + 1 ) 
else pduSize fi 



i Final fragment may 
\ be shorter than 
1 initial/intermediate 
! fragments. 



i Encryption expands 
\ each pdu by 
i sWepAddLng, 
] hence Mpdus may 
t be longer than 
]dot11MaxMpduLength 
i by sWepAddLng. 
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Procedure Encrypt 



i : fpar in/out wpdu Frame. 
[ in/out keyOk Boolean, 
i in maps KeyMapArray. 
| in mapLength KeyMapArray Length, 
i in kvec KeyVector. 
[inkndx Keylndex. 
i in caps Octetstring : 



lev field is 
encrypted, but 
this length 
is the pre-lcv 
loop count. 



encryptLngrs 
length(wpdu) - 
sMacHdrLng - 



'newlV:=s 
call genlV( x )' 



(true) 




=cPrivacy) 



kmap:= 
key Lookup 
(addrl (wpdu). 




(true) 



key:= 
kvec(kndx) 



T 



Return error 
to LLC if 

key is null. 



Concatenate 
key with IV 
for encryption 
PRNG seed. 



key:= key // 
PrngKey) 
newlV 



Use RC4 PRNG to i 
generate ah encrypt }.- 
string as long as the i 
MPDU payload ■ 
plus the ICV field. | 



encryptStr.o 
call RC4 
(key. 



encrypt, 1c(1) 



( 




) 






isWds:= 
toOs(pdu) and 
frDs(pdu) 



if isWds then 
sWdsAddLng 
else 0 fi 



del icv Crc ; K 
del encryptLng. k. n Integer ; ^ 
del encryptStr. newlV Octetstring 
del key PrngKey : 
del kmap KeyMap : 
imported procedure RC4 : 

fpar PrngKey. Integer ; 

returns Octetstring : 




1 Test if addr4 
\ field is present, 
t Only need at AP. 



if isWds then 
sWdsAddLng 
else 0 fi 



k:= 0. 
sWepHddng i 




i The IV generation algorithm 
— 1 is not specified, but use of 
i a new IV for each Mpdu is 
! recommended STRONGLY. 



ICV value i 
calculated from j- - 
plaintexL t 



Encrypt by xor ' 
of payload with [- - 
encrypt string, i 



icv:= crc32 
(icv.wpdu(n)) 



wpdu(n):= 
wpdu(n) xor 
encryptStr(k) 



maps, 

mapLength) 




i Use default 
- \ key if no 
• mapping or 
| group dest. 



/* The algorithm for changing 
dotHWepDefaultKeytd is not 
specified. If all stations in the Bss 
have thesame values in the 
{relevant subsetof) 

dot11WepDefaultKeys, 

a station's DefaultKeyld algorithm 
does not affect interoperability. 7 



(false) 



\ encr J 



keyOk:= 
true 



' If mapping 
■-|keyOn=false, 
i do not encrypt. 




n:= 0 



raw ICV is 1's 1 
complement of J- 
crc32. MSb-first i 



icv:= 
mirror( 
not(icvj) 





(true) 




keyOk:= 
false 



(icv(n) 
xor 

encryptStr(k)) 



Encrypt ICV 
octets and 
attach to end 
of Mpdu. 



wpdu:= 
wpdu // 







k:= 
n:= 


n+1 



{false) 



encryptLng+ 
sCrcLng) 




// newlV // 01 // 
substr(wpdu, sMac_ 
HdrLng, encryptLng) 



Insert IV and keyld 
between MAC header]--^ 
and data field. i 




Set WEP bit 
in Frame 
Control field. 



( 


rue) 


^^CrcLng^^ - 


wepdu:= 
setWepBit 
(wepdu.1), 




keyOk:= 
true 



(false) 
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Process PM_Filter_STA 



sta_PM_Bss_1b(4) 



I 



ResetMAC 



< import \ 
(mDisable) / 



del atPend. fsPend, K 
sentBcn Boolean: = fa Isq-T 

del cfQ, psQ. txQ, anQ 
SduQueue:= emptyQ : 

dci dpsm PsMode : 

del fsdu. rsdu FragSdu ; 

del k. n Integer ; 

del resl TxResult ; 

del sta MacAddr ; 



anQ:=emptyQ. 
cfQ:=emptyQ, 



psQ:=emptyQ, 
txQ:=emptyQ 










^Request 




/ (fsdu) 








1 IBSS case is 


Pdu_ 




-J two pages 


Request 


> 


t ahead. 


(fsdu) 




1 N 





Pdu_ 
Confirm 
(fsdu, resl) 



<Frag_ 
Confirm 
(fsdu. resl) 



d>C_) 



• Pass management frames 
*• -J involved in scan. join, 
i and start. 
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Process PM_Filter_STA 



sta_PM_Cfp_2b(4) 



Bss.Cfp 




<not import \ 
(mCfp) / 



(contention) 



PM.Bss 



Pdu_ 
Confirm 
(fsdu. res 








fsPend:= 
false 



CfPolled 



lxQ:= qlast 
(txQ. fsdu) 



(contention, 
free) 



cfQ:= qlast 
(cfQ. fsdu) 




ifsPend does not need 
.[to be checked because 
i there is exactly one 
'transmission opportunity 
] per Cf Poll. 



(con_ 
tention, 
free) 



Confirm 
(fsdu, res I) 



(con_ 
tention) 




fsdu!_ 
resume:= 
true 






txQ:= qfirst 
(txQ, fsdu) 







'set moreData 

bit in each 
fsdu fragment' 



Pdu_ 

Request 

(fsdu) 



cfQ:= qfirst 
(cfQ. fsdu) 



fsdu:= 
first(txQ). 
txO:= tail(txQ) 




Pdu_ 

Request 

(fsdu) 



fsPend:= 
false 



Send null SDU if i 
CFqueue empty. TxCtl [- — 
then responds with i 
CfAck or Null rather 1 
than Oata or OataAck. ! 



1 



Pdu_ 

Request 

(nullSdu) 
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Process PM_Filter_STA sta_PM_lbss_3c(4) 



Ibss data ' 
transfers (not J-- 
Atim window) i 



Request 
(fsdu) 



Pslnquiry 
(fsduldst) 



Wait_PS_ 
.Response 



psQ:= qlast 
{psQ, fsdu) 



PM_tbss_ 
_Data 



PM_lbss_ 
_Data 



T 



<not fsPendK 
and import > 
(mAtimW) / 



<not fsPend; 
and " 
(an' 



1 Announced queue 

-j has priority over 

i non-PM transmit queue. 



fsPendN J / 
t (length >>-< 1 
Q)/=0)/ \ 



X 




Pre_Atim 



1 Atim window 
-| is on next 
i page. 



PsResponse / 
( ,dpsm) \ 



_L 



(station_active) 



txQ:= qlast 
(txQ. fsdu) 



(length(anQ) 
= 0) and 
(length(txQ) 
/=0)) 



'{not fsPend\ 
d / 



X 



fsdu:= 
first(anQ), 
anQ:=tail(anQ) 



Pdu_ 

Request 

(fsdu) 



fsPend:= 
true 



fsdu:= 
first(txQ). 
txQ:=tait(txQ) 



Pdu_ 

Request 

(fsdu) 



fsPend:= 
true 



Frag_ 
Confirm 
(fsdu, rest) 



X 



Pdu_ 
Confirm 
(fsdu. rest) 



fsPend: = 
false 




fsdulpsm 
(true) J(false) 



txQ:= qfirst 
(txQ. fsdu) 



anQ:= qfirst 
(anQ. fsdu) 



AtimW 



PsChange 
(sta. psm) 




_X_ 



(<0) 



txQ:= 
qlast(txQ. 
psQ(n)) 








psQ:= 
subQ(psQ. 
0,n)//subQ( 




1 


psQ.n+1, 

length(psQ) 

-n-1) 





Copyright © 1999 IEEE. All rights reserved. 



337 



ISO/IEC 8802-11: 1999(E) 
ANSI/IEEE 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



Process PM_Filter_STA 



sta_PM_AtimW_4b{4) 



Pre _ Atim 







I 


/ • / 


AtimW / 










n:= 
length(anQ) 



i Wait until TxCoord 
- \ sends AtimW signal 
i to avoid chance that 
j Beacon fsdu reaches 
i TxCoord before the 
| TBTT signal is 
i processed by TxCoord. 



Move all 
anQ entries 
to psQ. 



Ibss during 
Atim window. 




Ensure that beacon 
is first fsdu sent 
during Atim window. 



AnoX atPendK 
\and (not imporO 
\ (mAtimW)) / 



sentBcn:= 
false 



PM_lbss_ 
_Oata 





(true) 


Pstnquiry \^ 


(fsduldst) ? < 


N 





Wait_PS_ 
.Response 







I 


/ • / 


PsResponse f 
( .dpsm) V. 



fsdu!psm:= 
true 




dpsm 

[(station, activey 



txQ;s qlast 
(txQ. fsdu) 



psQ:= qlast 
(psQ, fsdu) 




I 

<not atPendK 
and (length \ 
(psQ) /= 0)/ 



fsdu:= 
first(psQ), 
psQ:=tail(psQ) 



Pdu_ 

Request 

(fsdu) 



(atimAck) 



Pdu_ 

Request 

(fsdu) 



sentBcn:= 
true 



atPend:= 
true 



i Move fsdus 
y that arrive 
i before beacon 
| back onto end 
i of input queue. 



psQ:= qlast 
(psQ. fsdu) 



' Handling is 
--\ implementation 
i dependent, can 
| either re-queue 
> until next atim 
, window or retry 
i during this 
i atim window. 



PMJbss_ 
AtimW 
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Process Rx_ Coordination 



rx_coord_1a(4) 



aRxTxTurn_ 
aroundTime) 



first{import 
(mBrates)), 
stuff 

(aMpdu_ 

Duration, 

Factor. 

sAckCtsLng 
+ aPlcpHdr_ 

Length) 
+ aPream_ 
bleLength)) 




dSifsDly:= 
dUsec 
(aSifsTime - 



dRsp:=dUsec( 
aSifsTime + 
calcOur( 



1 Duration of 
PS-Poll and 
i Ack response. 




timer Tsifs 



3 



del acKFrom. ackTo MacAddr : f\ 
del dAck. dCts. dRsp. ^ 

dSifsDIy Duration : 
del endRx, strTs Time ; 
del pdu. rspdu Frame : 
del rxRate Rate : 
del sas. sau Station State : 
imported mNavEnd Time : 



No.Bss 



< import \ 
(mDisable) / 



mkOs(dAck). 
ackTo) 



set(endRx+ 
dSifsDIy. 
Tsifs) 






Wait 


_Sifs 



Tsifs 



TxRequest 

(rspdu. 

rxRate) 



^ Wail_TxDone j 



TxConfirm 



RxCJdle 



1 The rest of 
--J No.Bss state 
i is on 3rd page. 



RxCJdle 



Need Ack 
(ackTo.endR; 
dAck. rxRate) 



'RxCJdle state 
- \ continues on 
i next page. 



RxCfAck 
(ackFrom) 



dAck:= dAck - 
if dAck>0 then 
dRsp else 0 fi 



/^Ack(0,0) 



rspdu™ 
mkCtl 
(ack. 



RxCfPoll 



i No parameter 
-Rvalues because 
i without CfPoll 
] during Cfp the 
t transmitter 
j cannot send 
i after this ack. 




i Receipt of RxCfPoll 
\ while waiting to 
i send result of 
! NeedAck cancels 
i regular Ack wait 
\ and reports the 
i need for +cf Ack 
\ to TxCoord, which 

> will be in a 

| Sifs wait when 

> this signal 
! arrives. 
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Process Rx_ Coordination 



rx_coord_2b(4) 



RxCJdle 



Rxlndicate 
(pdu.endRx. 
strTs. rxRate) 



(ack) 



i RxCJdle state 
--j is continued 
(from previous page. 



I Class 1 frames handled 
■-] on this page, class 2 and 
i 3 frames on next page. 



Ack 

(endRx, 
rxRate) 



(cfend_ack 



Ack(O.O) 



(cfend) 



CfEnd 



(beacon, 
probe_req) 



(cts) 



Cts 

(endRx, 
rxRate) 



(authentication. 

deauthentication, 

atim. 

probe_rsp) 





(false) 



(data) 



import 
(mlbss) 
(true) "*<Zs^ ( fatse ) 




<Msdu_ 
Indicate 
(pdu. 



if import(mCfp) 
then contention_free 
else contention fi) 



RxCJdle 



Msdu_ 

Indicate 

(pdu. 



endRx.strTs, 
noerr) 



(rts) 



<Ss Inquiry 
(addr2(pdu)) 



Wait_Asoc_ 
^Response 



import( 



(true) 




(false) 



mNavEnd) 
> now 



>v Ss Response 
/ { .sas.sau) 




dur1d(rspdu)-dRsp. 
addr2(pdu)) 



i ' CTS respone to 
«* -]RTS only when 
i the Nav is clear. 



(true) 




Msdu_ 

Indicate 

(pdu, 



if import(mCfp) 
then contentionjree 
else contention fi) 



RxCJdle 
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Process Rx_ Coordination 



rx_coord_3b(4) 




i Beacon and probe_rsp 
\ sent to Mlme_ReqlRsp 
'while scaning, other 
| types acknowledged 
'{if unicast to this 
I station) but ignored. 



i At station 

\ Rx with toDs=1 

i discarded by 

|Filter_MPDU. 

ifrDs=1 never 

j sent by Sta, so 

( explicit fromDs 

j test not 

i needed here. 




(beacon. 
probe_rsp) 





(nuii_trame. disasoc, 






asoc_req, reasoc_req, 


(pspoll) 




asoc_rsp, reasoc_rsp) 





(data_ack, 
data_potl, 
data_poll_ack, 
cfack. cfpoll. 
cfpoll_ack) 




PsPoll should ' 
not be received |- • 
at station. i 
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Process Tx_Coordination_s(a 



sta_tx_init_1d(10) 



)/ \ timer Tifs. |\ 
Trsp.Tpdly: 4 



^ResetMAC 



Plme Reset, 
Request 



d Sifs Delay := 

dUsec 
(aStfsTime - 



'mmrate:= 
rate to send 
mmpdus' 



ssrc:= 0. 
slrc:= 0 



import 
(aCWmin), 



Backoff 
(ccw,-1) 



aRxTxTurn_ 
aroundTime) 



i Mm rate must be 
selected from 
tmBrates. Other 
j selection criteria 
[are not specified. 



dcfcw:= ccw, 
atimcw:= ccw 



^ TxC.ldle ^ 



/* at start of frame exchange K 

sequence, when setting mFxIP. ^ 

check if dot1lPowerManagementMode=curPsm. 

if not. when indicating the new Psm, 

also set psmChg boolean: 

at end of frame exchange 

sequence, when clearing FxIP. 

test & reset PsmChg. if 

true, send PsmDone to Mime V 



del atimcw, bstat, chan. ]\ 

defent. defew Integer ; 
del ccw Integers aCwMin ; 
del curPm Bit : 
del doHop. psmChg, cont 

Boolean- false ; 
del dSifsOelay. endRx Time ; 
del fsdu FragSdu ; 
del rtype Ftype ; 

del seqnum. ssre. sire, n Integers 0: 
del tpdu Frame : 
del txrate Rate ; 



del exported FxIP Boolean:= false ; K 
del cTfrg exported as ^ 

doM 1 Transmitted FragmentCount. 
del cTfrm exported as 

dot1 1 Transmitted FrameCount 
cTmcfrm exported as 

doM 1 MulticastTransmitted FrameCount, 
cFail exported as dotl IFaiiedCount, 
cRtry exported as dot 1 1 Retry Count. 
cMrtry exported as dot11MultipleRetryCount. 
cCts exported as dot1 IRtsSuccess Count. 
cNcts exported as dotHRtsFailureCount. 
cNack exported as dot11AckFailureCount 
Counter32:= 0 ; 



Imported dotl 1 RtsThreshold. N 

dotnShortRetryLimit, L ~ 

dot11LongRetrylimit, 

dotl 1 Fragmentation Threshold, 

do!1 1 MaxTransmitMsdu Life time Integer. 

mPdly Usee ; 



/* RANDOM NUMBER FUNCTION V 
imported procedure Random ; 
fpar limit Integer ; returns Integer ; 
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Process Tx_Coordination_sta 



sta_tx_idle_2d(10) 



1 These transitions are 
^--j only present at 
| i Cf-pollable stations. 




fsdu!sqf:= 
seqnum. 



seqnum:=if seqnum=4095 
then 0 else seqnum+1 fi, 
fsdu!eol:= now + import (dot11Max_ 
TransmitMsduLifetime) 



BkOone 
(dcfcnt) 



tpdu:= 
setSeq(tpdu, 
fsdulsqf) 



tpdu:= 
fsdujpdus 
(fsdulfCur) 



"txrate:* 
selected tx 
data rate' 




t See 9.6 for rules 
- -| about selecting 
i transmit data rate. 



i With FH PHY, 
\ if next fragment 
i will be after a 
| dwell boundary, 
i Duration/ID 
| may be set to 
' one ACK time 
| plus SIFS time. 




import(mBssld). 
import(mBssld). 



(true) 



dcfcw:-ccw, 
ccw:=atimcw 



<: 



tpdu:= 
setDur1d(tpdu, 
calcDur(txrate, 







tpdu:~se 
tpdu, i 
dot1 1 Po\ 
agemen 


tPwnVIgt( 
mport( 
verMan_ 
itModo)) I 



(aSifsTime + (calcDur(tx rate, stuff 
(aMpduDurationFactor.sAckCtsLng)) 
+ aPlcpHeadeitength + aPreamble_ 
Length) + if (fsdulfTot = (fsdu!fCur+1)) 
then 0 else ((2*aSifsTime)+(ca!cDur 
(txrate,stuff(aMpduDurationFactor, 
sAckCtsLng)) + aPlcpHeadertength 
+ aPreambleLength) + stuff(aMpdu_ 
OurationFactor,((length(fsdu!pdus 
(fsdulfCur* 1)) + sCrcLng)*8)) + aPlcp_ 
HeaderLength + aPreambleLength) ))) 



Atim_ 
Window 



sCrdng) > import(dotHRtsThreshold)) 
and (not fsdulgrpa) and ((fsdu!fCur=0) 
or retry(tpdu) or(fsdu! resume)) 




i This assumes that the data 
- \ rate change (if any) is at the 
i end of the Plcp header. The 
\ IR PHY, changes rate in the 
• middle of its Plcp header, so 
[the Duration/ID value may 
■ be adjusted when using IR 
! PHY non-basic data rates. 



stuff (aM pd uDuration Factor, 

((length (tpdu )+sCrcLng)*8))+ 

aPlcpHeaderLength+ 
aPreambleLength* (3*aSifsTime)+ 

(2*calcDur(txrate, stuff (aMpdu_ 
DurationFactor,sAckCtsLng))+ 
aPlcpHeaderLength+aPreambleLength) ) 
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Process Tx_Coordination_sta 



sta_tx_dcf_3d(10) 




Wait Cts 



stuff(aMpduD_ 
u ratio nF actor; 
sAckCtsLng))* 
aPlcpHeadert_ 
ength+aPream_ 
bleLength+aSI_ 
otTime), Trsp) 













TxConfirm 


m 








set(now+dUsec 
(aSifsTime + 
calcDur(txrate, 




stuff(aMpduD_ 

uration Factor. 

sAckCtsLng))+ 

aPlcpHeaderL_ 

ength+aPream_ 

bleLength+aSL 

otTime), Trsp) 






Wait 


Ack ] 



cNack:= 
inc(cNack) 



export(cNack) 
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Process Tx_Coordination_sta 



Cts 

(endRx. 
txrate) 



reset 
(Trsp) 



ssrc*0, 
fsdu!src:=0 



cCts:= 
inc(cCts) 



export(cCts) 



set(endRx 
♦dSifs Delay. 
Tifs) 



tpdu:= 
setOur1d(tpdu. 
calcDur(txrate. 



Wait.Cts. 
_Sife 




stajx_dcf_3.1d(l0| 



^ Wait.Cls j 



f :nfrm A 
\odu~y 



Trsp 



cNcts:= 
inc(cNcts) 



export(cNcts) 




slrc:=0, 
ssrc:=0. 




fsdu!lrc=0. 
fsdu!src:=0 








cTfrg:= 
inc(cTfrg). 
cTmcfrm:a 




If (fsdu.'grpa or ((toOs(tpdu) = 1) 
and (isGrp(addr3{tpdu))) 
and (fsdu!fTot=fsdu!fCuM-1))) 
then tnc(cTmcfrm) 
else cTmcfrm fi 





\(sdu!fCur+V^ 
(true) 



cTfrm:* 
inc(cTfrm) 



(false) 




(aSifsTime + (calcOur 
(txrate, stuff (aMpdu_ 
DurationFactor.sAck 
CtsLng))+aPlcpHeader_ 
Length+aPreamWeLength) 

♦ if (fsdulfToto (fsdul 
fCur*1))then 0 etse 
((2*aSifsTime)+(caJcOur 
(txrate. stuff (aMpdu_ 

Du rationFador. sActt 
OsLng)) * aPlcpHeader. 
Length ♦ aPreambleLen_ 
gth)*3tufl(aMpduDuration_ 
Factor, ((length (fsdulpdua 
(fedulfCur+1))*sCrcLng) 
*8)) ♦ aPlcpHeadertength 

♦ aPreambleiength) ))) 



TxC_ Backoff 





(false) 




fsdu'fCur.s 
fsdu!fCur+1 



TxC.ldle 
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Process Tx_Coordmation_sta 



sta _ retry _4d( 10) 




f ack ^ 



mFxlP:=false 



mFx!P:sfalse 



export 
(mFxIP) 



export 
(mFxIP) 



ccw:= if 
ccw = aCWmax 



ccw:= if 
ccw a aCWmax 



then aCWmax 
else (2*ccw)+1 
fl 



then aCWmax 
else (2*ccw)+1fi 



Backoff 

(ccw.-l) 



Backoff 
(ccw.-l) 



tpdu:= 
setRetry 
(tpdu.1). 



fsdulpdus (fsdu!fCur):= 
setRetry {fsdu!pdus( 
fsdu!fCur),1) 



(false) 



import(dot11Long_ 
RetryLimrt) 



(true) 




(true) 




sCrcLng) > 

import(dot1 1 RtsThreshofd)) 



ssrcs 




fsdu!src:= 


ssrc+1. 




fsdu!src*1 



PduConfirm 
(fsdu. 
retry Limit) 



cFail:» 
inc(cFail), 
cont:s false 



export(cFail) 



import(dot11Long_ 
RetryLimrt) 



(false) 



(true) 




import(dot11ShorL 
RetryLimrt) 



import(dot1lShort_ 
RetryLimrt) 



(false) 



coM: a true 



J- 



TxC_ Backoff 



i This shows the case where the 
-\ same pdu is rethed after the 
i backoff, tt is also allowable to 
[ return this fsdu to PM_Filter wrth 
i statusspartial, and to go to 
| TxC_ Backoff slate with cont=fa!se. 
■ This will allow a different pdu 
| (if available) to be sent as the 
i next transmission. 
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Process Tx_Coordmation_sta 



Attm_ 
Window 



/ not import \ \ £ du - 

\< mA " mw >/ /est 



1 Ack. CfPoll. Cts, Doze, 
-■•MmCancel. Tbtt. TxCfAck 
r and Wake ignored in this slate. 



' PM.Filter ensures that a 
■-} beacon frame will be the 
i first first sent after Tbtt. 





[(beacon) 



cont= false 



n:= call 


Random 


(2*aCWmin) 






Backoff 




<n.-l) 


> 




r 



Backoff 

(CCW.-1) 



Ibss.Wait. 
Atim 



^ TxC.ldle j ^ TxC. Backoff j ^ '^ea^on" j 



<not import \ 
(mAtimW) / 



BkDone 
(bstat) 



MmCancel 



TxRequest 
(fsdu!pdus(l), 
mmrate) 



atimcw:=ccw. 
ccw:=dcfcw 



Cancel 



TxC.ldle 



Wait, Beacon. 
.Transmit 









•7 


TxConfirm / 







Wait.Beacon. 
.Cancel 



BkOone(n) 



Atim 
.Window 



JZ 



Atim. 
.Window 



sta Jx_atim_5e(10) 



fsdu!dst. 

dotltMacAddress) 



BkDone 
(bstat) 



TxRequest 

(tpdu. 
mmrate) 




dRsp:*dUsec( 
aSifsTime + 
calcDur( 




txrate, stuff 
(aMpdu Duration. 
Factor, sAckCtsLng 
+ aPlcpHdrtength) 
+ aPreambteLength)) 






set 

(now+dRsp. 
Trap) 











Wart.Atim. 
Ack 



Copyright © 1999 IEEE. All rights reserved. 



349 



ISO/IEC 8802-11: 1999 (E) 
ANSI/IEEE 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS; WIRELESS LAN 



Process Tx_Coordination_sta 



sta_tx_atim,5.1a(l0) 




Wait.Atirn 
Ack 



Ack( . ) 



ccw;s 
aCWmin 



PduConfirm 

(fsdu. 

atimAck) 



fsdu!fAnc:= 
fsdu!fCur+1 



(false) 



PduConfirm 

(fsdu, 

atimNak) 



Atim_ 
.Window 



\-Trsp 










ccw:= if 
ccw = aCWmax 




then aCWmax 
else (2'ccw)+1 
fi 








ssrc:=s 
ssrc+ 1 . 




fsdu!src:= 
fsdu!src-M 




tmport(dot1l_ 

ShortRetry_ 

Limit) 
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Process Tx.Coordmation sta 

sta_backoff_6c(10) 



TxC, Backoff 







1 1 


^>TBTT 


\BkDone 
/(bstat) 


/ • 




• If cont=true. 
- \ continue with 
\ same mpctu. 



Sync sends 
Wake at Tbtt 
before other 
signals such 
as TBTT 
or beacon 
frame. 



Ooze 



turn off 
stuff to 
save power* 



PlmeSet. 
request 
(doze stuff)' 



Asleep 



_r 



Pdu_ 

Request 

(fsdu) 



Wake 



lum on 
stuff that 
was off 



lum on 
stuff that 
was off 



'PlmeSet._ 
request 
(wake stuff)' 



Wait for Probe > 

Delay interval { r 

before starting ■ 

transmission. ! 



\ SwChnl 

^(chan. 
/ doBkoff) 



ChangeNav 
(O.cswitch) 



'channel 
change is 
Phy-spebfic' 



"PimeSet._ 
request 
(chan stuff)' 



/ Wait. \ 
I .Channel J 



PlmeSet. 
confirm 
(status stuff)* 




Backoff 

(CCW.-1) 



SwChnl. 
.Backoff 











BkOone / 
(bstat) \ 
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Process Tx_Coordination_sta 



sta_ cf_ respond _7c( 10) 



CfPoll 
(endRx. ) 



tpdu:=mkframe 

(nulMrame. 
mBssld.mBsstd) 



set(endRx + 
dSifsDelay. 
Trsp) 



CfPolled 



Cf_ 
.Response 



TxCfAck 



tpdu:=mkframe 

(cfack, 
mBssld.mBssId) 



else 



tpdu:= 
setSeq{tpdu. 
fsdulsqf) 



tpdu:« 
setFtype 
(tpdu. 




Pdu_ 

Request 

(fsdu) 



pack:* 
ftype(tpdu) 



tpdu:= 
fdsulpdus 
(fsdulfCur) 




fsduleol 



fsdulsqf:* 
seqnum. 



flype(tpdu) 
or pack) 



j Transitions on this 
TxC^Cfp Page are only present 

i if station is Cf-pollable. 



<not import \ 
(mCfp) / 



TxCJdle 



CfEnd 



Trsp 



seqnum:=seq_ 
num+1, 

fsduteof:* now* 
import(dot11_ 
MaxTransmit. 
MsduLrfetime) 



Urates 
selected tx 
data rate' 



, 1 , 

| See 9.6 for rules ,.| ' Change data to 
- * about selecting ^ -] data+cf Ack if 
i transmit data rate-. i appropriate. 



Wait Cfp_ 
Sifs 



TxCfAck 
(endRx) 



rtype:= 
cfAck 



tpdu;* 
mkFrame( 
rtype. 




Trsp 



TxRequest 

(tpdu. 

txrate) 



cTfrg;s 
inc(cTfrg), 



export 
(cTfrg. 
cTmcfrm) 



Wait_Cfp_ 
TxDone 



TxConfirm 



set(now+ 
aSifsTime. 
Trsp) 



import(mBssld). 
tmport(mBssld) ) 



Wait Cfp 
Sifs 



TxCfAck 



tpdu:= 
setFtype 
(tpdu.data ack) 



cTmcfrm:= 

if (fsdulgrpa or 

(( toOs(tpdu) s 1) 

and (isGrp(addr3(tpdu))) 

and (fsdu!fTot=fsdu!fCur+1))) 

then inc(cTmcfrm) 

elsecTmcfrm fi 



Wait.CfAck 
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Process Tx_ Coordination _sta 



sta_cf_retry_8b(10» 



Wait_CfAck 



Ack 

(endRx. ) 



Trsp 



t Send frame 
*» at Stfs 




set (endRx 
♦dStfs Delay, 
Tife) 



tpdu:= 
setPwrMgt 

(tpdu.curPm) 



Wait.Sife 



Tife 



TxRequesI 
(tpdu.trate) 



I Watt_Tx_ \ 



TxConfirm 



TxC.ldle 



reset(Trsp) 



(true) 



PduConfirm 

(fsdu. 

success) 



cTfrm:= 
inc(cTfrm) 





cNack:= 
mc(cNack) 



fsdulfCurO 



< PduConfirm 
(fsdu. 
txLife) 





(false) 




fsdu.'fCur:* 
fsdu!fCur*1 



Txc.ap 







export 
(cNack) 






tpd 
setF 
(tpd 


u:» 

tetry 

u.1). 



fsduipdus 
(fsdu!fCur):= 
set Retry 
{fsduipdus 
(fsdu!fCur).1) 



(true) 



PduConfirm 

(fsdu, 

retryLimit) 




import(dot11Long_ 
RetryLimit) 



PduConfirm 

(fsdu. 

partial) 



cFail:* 
inc(cFail) 



cRtry:s 
inc(cRtry) 



export(cFail) 



■ This returns the fsdu 
\ to the queue. At the 
i next cf-poll. either 
[ the same fsdu or a 
i different fsdu may 
] be selected for 
i transmission. 



export(cRtry) 



TxC.Cfp 
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Block Transmission 



/* This block does octet- K 
level transfers of MPDUs ^ 
from the MAC to the PHY 
transmitter, generating 
FCS fields and inserting 
timestamp values where 
necessary. Process Data_ 
Pump begins transmttting 
when TxRequest arrives. 
The sender of TxRequest 
is assumed to have done 
the appropriate actions 
prior to transimtting onto 
theWM. If these actions 
include performing random 
backoff or invoking the 
"backoff procedure" (see 
9.2.5.2). a Backoff signal 
is sent to process Backoff. 
At the completion of each 
backoff, a BkDone signal 
is returned to the sender 
of the Backoff signal at 
the correct time to send 
a TxRequest. The medium 
state updates (busy. idle, 
slot) from Channel, State 
are forwarded to Backoff, 
Procedure via Data _ Pump 
to prevent decrementing 
the backoff count while 
transmttting Cts or Ack 
frames. This block is used 
in both station and AP. */ 



j^TxConfirmj 



Txrq 



transmittal t) 



Bkof 



[Backoff. 
Cancel 



Backoff Procedure 
(1.1) 



7fC 



j^TxRequestJ 



FwdCs 



Data Pump 

0.1) 



Busy, 

Idle. 

Slot 



FromCs 



^Busy. Idle. Slot J 



PhyTxStart.conftrm, 
PhyTx End. confirm. 
PhyOata. confirm 



ToPHY 



PhyTxStart request, 
PhyTxEnd.request. 
PhyOata. request 



PHY.SAP.TX 
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Process Oata.Pump 



Oalay from 
; -|PMy_SaD(tx) 
i to antenna. 



(Txjdle) 



del fes Crc : y 
del dTx L 

Ou ration ; 
del k. txLength 

Integer : 
del pdu Frame : 
del rate Octet : 
del source Pld : 



tm ported N 
procedure Tsf 
fpar Integer. 
Boolean: 
returns Integer : 




> ResetMAC 



dTx:= dUsec 
(aTxRfDelay + 
aTxPlcpOelay) 



PhyTxEnd.. 
request 



1 No TxConfirm 
--|if Tx halted 
i by ResetMAC. 



1 Do not wart 
- -J for TxEnd._ 
i confirm. 



fcs:= crc 32 
(fcs.pdu(k)) 



^ Txjdle j... 



| Pass Busy. Idle and Slot signals 
*, to Backoff. Procedure while Tx is 
but not during transmissions. 








Send 


_CRC ^ 


\ 








PhyOata. / 


confirm 


\ 



transmit _ 1 a{ 1 ) 



Send. Frame ^ 



PhyOata.. 
confirm 



T 



r This process sends an j\ 
Mpdu to the Phy while ^ 
generating & appending 
the Fes. On beacons and 
probe responses inserts 
(TSF + Phy TxDelay) in 
the timestamp field at 
confirm of octet 23. 

To transmit after Sits, 
send TxRequest at end 
of the Ml interval (see 
9.2.10). For Pifs. Difs. 
or any backoff slot 
TxRequest is sent at the 
end of the appropnate 
M2 interval. 7 



i Send the Vs 
-\ complement 
i of calculated 
' FCS value. 
,MSbto LSb. 






(true) 




PhyTxEnd.. \ 
request > 


\ 




^ Wart.TxEnd 
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Process Backoff_Procedure 



backoff. 1o(2) 



^ No,Backoff ^ 



cw is contention 
window, cnt is 
slot count from 
previous BkDone. 
If cnt<0. a new 
random count 
is generated. 



Backoff 

(cw. cnt) 



/* This process performs the N 
Backoff Procedure (see 9.2.5.2). ^ 
returning Done(-1) when Tx may 
begin, or Done(n>=0) if cancelled. 
Back off (cw.-l) starts new random 
backoff. Backoff(x.n>=0) resumes 
cancelled backoff. Backoff(O.O) 
sends Oone(-I) when WM idle. */ 



source: = 
sender, 
rnBklP:=tnje 



1 Save Pld from 
--J request to use 
i as addr of Done. 





(<0) 


Choose random • 
backoff count ]---■ 
ifcnt = -1. ( 


slotCnt* call 
Random(cw) 





At start assume that the WM 
is busy until receiving a signal 
which indicates the WM is idle. 




Transitions to 
Channeljdle 
also align the 
Backoff signal 
arrival time to 
slot boundary 
(M2) timing. 




1 Resume with count 
- -j from cancelled 
i backoff if cnt>=0. 



/* Input Signal Summary 
BUSY is sent by Channel_State 
when the WM changes from idle 
to busy due to CCA and/or NAV. 
and by Data_Pump at TxStart. 
CANCEL is sent by TxCoordination 
to terminate a backoff and return 
the residual backoff count value. 
IDLE is sent by Channel, State at the 
end of the M2 interval (see 9.2.10) 
that busy WM has been idle (CCA & 
NAV) for DIFS (EIFS after Rx error). 
SLOT is sent by Channel, State at the 
end of each M2 interval (see 9.2. 10) 
while the WM is idle. 
Busy. Idle and Slot are forwarded 
from Channel.State via Data_Pump 
when transmit is not in progress. */ 









1 1 1 


Idle 


Slot , 


Busy / ^Cancel 




<- , --- ! 





Channeljdle 




Slot only sent 
when WM idle. 
This is for the 
case where WM 
idle at arrival of 
Backoff signal. 



snd 
, BkDn 



del slotCnt 
cw, cnt 
Integer : 
del source Pld: 
del exported 
mBkIP 
Boolean: = 
false ; 



r RANDOM NUMBER FUNCTION v|\ 
imported procedure Random : L ^ 
fpar limit Integer ; returns Integer 
/* This function returns an integer 
from a uniform distribution over 
the range (0 <= value <= limit). 
Implemented need to be aware 
that proper operation of the MAC 
protocol requires statistically 
independent ( pseud o-) random 
sequences to be generated by 
each station in a service area. V 
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Process Backoff, Procedure 



backoff. 1.1 a( 2) 




< Idle signal 
\ not sent if 
; WM free. This 
, consumes any 
'Jdies still on 
i input queue. 
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SM_MLME_SAP 



Block MAC .Management. Service 



M ImeGet. confirm. 
MlmeSet confirm, 
MlmeResetconfirm 




GetSel 



This process is 
a summary of 
MIB access. 
MIB attribute 
definitions 
(in ASN.1) are 
in section C.4. 



MlmeGet. request. 
MlmeSet. request 
MlmeReset. request 



MIB (1,1) 



M I meReset. request 
sends a ResetMAC 
signal to every 
process in every 
block. To reduce 
diagram clutter. 
ResetMAC signal 
routing is not shown 
outside this block. 



Mres 



Mac_Mgmt_1a(1) 



ReqConfirm 



M I meAsscoate. confirm. 

MlmeAuthenticate. con firm, 

MlmeDeauthenticate.confirm. 

MlmeDisassodate.confirm. 

MlmeJoin. confirm, 

M ImePowermgt.confirm, 

MlmeReassociate, confirm. 

MlmeScan. confirm. 

M I meStart. confirm 



M ImeAs sociate. req u est 
MlmeAuthenticate. request. 
Ml me Deauthenticate. request. 
MlmeOis as sociate. request. 
MlmeJoin.request, 
M I mePowermgt request. 
MlmeReas sociate. request 
MlmeScan. request 
MlmeStart. request 



MlmeAssociate. _ 
indication. 
MlmeAuthenticate. _ 
indication. 

MlmeDeauthenticate.. 

indication. 

MlmeDisassoaate._ 

indication. 

MlmeReassociate.. 

indication 



This process handles 
requests sequentially. 
Start, pin, powermgt. 
scan, re/d is/associate 
and deauthenticate 
must be sequential. 
It is possible to have 
multiple authentication 
sequences in progress 
concurrently. To allow 
this, AuthReq. Service 
in the MLME block 
would have to cache 
challenge text and 
match responses to 
cached request info. 



[ResetMAcJ 



Mime Requests 

(1.D 



Mime Indications 
(1.1) 



r In this block are N 
the MAC MIB and ^ 
MLME.SAP service 
primitives described 
in Clause 10. The 
MLME services are 
performed in the 
MLME block. This 
block is used both 
in station and AP. 7 



ToMgt 



MlmeAssociate. confirm. 
M ImeAuthenticate .confirm. 
M ImeOeau th enticate . confi rm, 
MimeOisassoa ate. con firm. 
MlmeJoin.confirm. 
M ImePowermgt.confirm. 
MlmeReas sociate. confirm, 
MlmeScan. confirm. 
MlmeStart. confirm 



MlmeAssociate. request 
M ImeAu th enticate .request, 
MlmeDeauthenticate. request. 
MlmeOis associate. request. 
MlmeJoin.request. 
MlmePowermgt. request. 
MlmeReassociate. request 
MlmeScan. request. 
MlmeStart. request 



MlmeAssociate.. 
indication. 
MlmeAuthenticate.. 
indication. 

MlmeDeauthenticate.. 

indication, 

MlmeOisassobate.. 

indication. 

MlmeReassociate.. 

indication 



FromMgt 



MMGT 
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Process Mlmejndications 



Mlme_mdtcation_la(t) 



del alg AuthType 
del rsn ReasonCodi 
del sta MacAddr 



Pass, 
Through. 
Idle . 



J This state machine passes indications through, unmodified, from 
■ MLME to the MLME SAP. MlmeAssociate. indication and 
i MlmeReassociate. indication are only generated by MLME at APs. 



MlmeAsso. 

ciate.ind. 

ication(sta) 



X 



MlmeAuthen. 

ticate.ind_ 

icationtsta.atgj' 



<MlmeAsso_ 
ciate.md. 
tcation(sta) 



X 



MlmeDeauth / 

enticate.ind_<^ 

ication(sta.rsnK 



MlmeAuthen . 

ticate.ind. 

ication(sta.al<)> 



X 



MlmeDisas 
sociate.md, 
ication(sta.rsnf 



MlmeDeauth 
enticate.ind. 
ication(sta) 



MlmeReas, 
sociate.ind_ 
ication(sta) 



< MlmeDisas. 
sociate.ind. 
ication(sta) 



MlmeReas. 
sociate.ind. 
ication(sta) 
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Process MIB 



Mib_access_la(2) 



del x MibAtnb : |\ 
del v MibValue ^ 
del adr MacAddr 
del dftt Boolean : 



MlmeRe_ 
^set.request 
/ (adr.dflt) 



/* This process performs |\ 
MlmeGet MlmeSet. anir 
MlmeReset functions. 
MIB access and update 
is desenbed informally 
to avoid creating a full 
definition of the MIB 
in SDL (and anticipating 
the integration of the 
ASN.1 MIB definition 
using Z. 105). V 



ResetMAC 




dfrt 



(false) T(true) 



'reset read-wnte 

attributes to 
default values' 



dotl1MacAddres< 
set to adr if 
adr is non-null* 



'export values 
of attributes 
declared here' 



<Mlme_ 
Reset.con_ 
firmfsuccess; 




t ResetMAC is sent to all processes 
-t in all blocks. However, to reduce 
'clutter and enhance readability. 
J ResetMAC is omitted from signallists 
| signal routes needed solely for 
, the ResetMAC signal are not shown. 



> Reset read-wnte attributes in the MAC 
~ i MIB. The write-only attributes in the 
J privacy group may also be reset. 
, If there is a (non-Mime) means to alter 
j any of the read-only attnbute values, 
i they must be restored to default values. 



[ A locally-administered MAC address 
■J may be used in lieu of the unique, 
i globally-administered MAC address 
| assigned to the station. However, the 
j value of dot1 1 MacAddress may not change 
i during MAC operation. 



(*read_only*) 



MlmeSet. 
confirm 
(read-only .x) 



Mr- 
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Process MIB ' ~ 

Mibjmport_export.2b(2) 



'* Import of (Read-Only) MIB counter f\ 
values exported from other processes 7 ^ 
imported 
dott lAckFailureCount, 
dottlFailedCount, 
dott 1 FcsErrorCount 
dot! IFrameDu plicate Count. 
dot1 IMulticastReceivedFrameCount, 
dott t MulticastTransmrttedFrameCount. 
dot1 IMuttipleRetryCount 
dot1 iReceivedFragmentCount. 
dot1 1 RetryCount. 
dott 1 RtsFailureCount 
dot1 IRtsSuccessCount. 
dot1 ITransmittedFragmentCount, 
dotl 1 WepExcludedCount, 
dotl IWeplcvErrorCount. 
dott IWepUndecryptableCount Counter32 



/* The following Read-Only attnbutes in the h 
MAC MIB are defined as synonyms (named L 
constants) rather than remote variables 
because they describe properties of the 
station which are static, at least during 
any single instance of MAC operation: 

dot11AuthenticationAlgorithms AuthTypeSet 

dotUCfPollable Boolean. 

dotHMacAddress MacAddr. 

dotllManufacturertO Octetstring, 

dotllPnvacyOptionlmplemented Boolean, 

dot11ProductlO Octetstnng, 

aStationlD MacAddr, 

dotllWepKeyMappingLength Integer; 

In addition, all Read-Only attributes in the 
PHY MIB whicri are accessed by the MAC 
are defined as synonyms. 



/* Declarations of MIB attnbutes exported from 
this process V 

/' Read-Wnte attributes 7 
del exported 
dotl 1 AuthenticationAlgonthms AuthTypeSet* 
m cl (open .system. shared_key). 
dot11ExcludeUnencrypted Boolean:* false. 
dot11 Fragmentation Threshold Integer* 2346. 
dotl IGroupAddresses MacAddrSet* empty. ' 
dot11LongRetryLimit integers 4. 
dot11MaxReceivelifetime Kusec:*512. 
dot11MaxTransmitMsduLifetime Kusec* 512. 
dotllMediumOccupancyLimrt Kusec* 100. 
dot11Privacylnvoked Boolean:* false, 
mReceiveOTtMs Boolean:* true. 
dot11CfpPenod Integer? 1. 
dotnCfpMaxOu ration Kusec:= 200. 
dotl 1AuthenticationResponseTimeout Kusec:* 512 
dot11Rts Threshold Integer* 3000. 
dotl IShortRetryLimit Integer* 7, 
dotllWepOefaurtKeyld Keylndex:*0. 
dotl ICurrentChannelNumber Integer* 0. 
dotUCurrentSet Integer* 0, 
dotl ICurrentPattem Integer* 0. 
dotl ICurrentlndex Integer* 0 : 

/* Write-Only attributes 7 
del exported 
dotl IWepOefaultKeys Key Vector* nullKey. 
do111WepKeyMappings 
KeyMapArray:* (. nullAddr, false. nullKey .) : 



/* NOTE: X 
The values listed for MAC MIB attributes are the^ 
specified default values for those attributes. 
The values listed for PHY MIB attnbutes are either 
the default values tor the FH PHY, or arbitrary 
values within the specified range. The specific 
values for PHY attnbutes in this SOL description 

^ of the MAC do not have normative significance. 
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Process Mlme_Requests 



Mime, request J b(3) 



del exported mActingAsAp [\ 
Boolean- fafse : ^ 

imported mAssoc. 
mlbss Boolean : 



newtype MRqState 
literals idle. bss. ibss. a 
endnewtype MRqState 

del rqState 
MRqState:** idle : 




export 
(mActing_ 
AsAP) " 



/' This process tracks K 
the synchronization state^ 
of the station as Idle 
{not part of any Bss). 
Ibss (started or joined 
an independent Bss). Bss 
(joined an infrastructure 
Bss). or Ap {started an 
infrastructure Bss). 
Mime operation requests 
invalid in the current 
state are rejected here, 
while valid requests are 
passed to the Mime block 
for processing. This 
simplifies process flow 
and signal saving in the 
Mime block, because only 
meaningful Mime requests 
arrive for handling. V 



del alg AuthType : K 

del bRate, oRate. ss Octetstring-r 

del bss BssOscr ; 

del bssSet BssDscrSet : 

dc! fctypQ Bss Type : 

del cap Capability : 

del cfpm CfParms : 

del chlist Intstring : 

del dtp. h Integer : 

del dly Usee ; 

del ibpm IbssParms : 

del phpm PhyParms : 

del ps PwrSave : 

del rs ReasonCode : 

del scan Scan Type : 

del st a. bid MacAddr ; 

del sts MlmeStatus : 

del tBcn. tmax. tmm. tmot Kusec 

del type Set BssTypeSet ; 

del wake, rdtm Boolean : 



IDLE 



i Reject Authenticate, 
"""i allow Start if idle 



Reject Start if 
not idle, allow 
Auth if neither 
IDLE nor AP. 



(IDLE. AP) 



Mlme_ 
Start., 
request 



(ss. btype. tBcn. 
dtp. cfpm. phpm. 
ibpm. dly. cap. 
bRate. a Rate) 



\ MlmeAutfi, 

y enticate.re_ ■ 
/ quest{sta. , ) 


1 Reject as invalid 
---{ due to not being 
i in a BSS. 






/ MlmeAuth. 
^ enticate.. 
N. confirm 


(sta. 
invalid) 




>MlmeAuth_ 
enticate._ 
request 



MlmeAuth_ 

enticate.. 

request 



Wait.Mlme 















^>ResetMAC 


\^ MlmeDeauth 
y enticate. re. 
/ quest(sta.rs) 










rqState:° idle. 

mActing_ 
AsAp;s false 




MlmeDeauth _\ 
enticate.. \ 
request(sta.rsl/ 



{IDLE) 



MlmeStart. 
request( , . 



(sta. alg. 
tmot) 




(sta, alg, 
tmot) 



<MlmeStart._ 
confirm 
(alreadyBss) 



( \ \ 1 Reset and / \ 
(■---[Deauth enticate [ - I 
/ i always allowed. \ J 



i Deauthenticate 
- \ expunges local 
i authentication 
J record even if 
i there is no BSS 
J for sending the 
i notification. 




Wait.Mlme 
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Process Mlme_ Requests 



Mlme_request_2c(3) 



BSS 



< Allow Associate 
--■[and Reassoctate 
i while joined Bss. 



\ Mime. 

^Associate.. 
/ request 





(true) 


/ MlmeAssoc. 
( iate.confirm 
(invalid) 










\. MlmeRe. 
y associate.. 
X request 



(sta. tmot. 
cap.li) 



(false) 



Mlme_ 
Associate., 
request 



^ ( Wait j 
( AP 




1 Reassociate request 
- *] rejected as invalid 
i if not associated. 



MlmeRe 




associate.. j 


request 









(sta. tmot 
cap.li) 



J ^ Wart.Mlme j 



1 Reject Scan. Join 
■*i and Powermgt; allow 
i Oisassociate at AP. 



(BSS) 



MlmeScan., 
request 

( ) 



MlmeJoin.. 
request 

(...) 



MlmeScan.. 
confirm 
( .invalid) 



MlmePower. 
mgt.request 

(..) 



MlmeJom.. 

confirm 

(invalid) 



_L 



MlmeDisas. 

sociate.re. 

quest(sta.rs) 



MlmePower. 
Mgt.confirm 
(not.supt) 



( ^ ) ' 



1 Reject Associate and 
- ■ Reassociate at AP and 
i at station not joined Bss. 



MlmeDisas_ 

sociate.re_ 

quest(sta.rs) 



Wart.Mlme 











\ Mlme_ 

^Associate.. 
/ request(. ,.) 


MlmeRe_ 
\ associate., 
/ request(. . ,) 








/ MlmeAssoc. 
^ iate. confirm 
\ (invalid) 


/ MtmeReas_ 
^ sociate.con_ 
\firm( invalid) 




£ . \ 





| If not AP. allow Join. Scan 
■ and Powerrngt. also allow 
i Disassociate tf associated. 



1 Only AP may send 
/y x disassociate to a 
i group address. 



\. MlmeScan.. 
")» request 
/ (btype.bid. 




ss. scan, 
dry. chlist, 
tmin. tmax) 








MlmeScan ._ \. 
request \— 
(btyoe.bid. / 


ss. scan, 
dfy. chlist. 
tmin, tmax) 








Wart. 


Mime j 


i 1 — v 

MlmeJoin.. X 
request*. \ 
bss.tmol.dty.y^ 



oRate) 




oRate) 



MlmeOisas. 

sociate.re. 

quest(sta.rs) 



Wart.Mlme 



Wart.Mlme ( - j 



Copyright © 1999 IEEE. All rights reserved. 



363 



ISO/IEC 8802-11: 1999(E) 
ANSI/IEEE 802.11. 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



Process Mime Req-jests ,„ 
- M Mime _ response _3a(3) 



i t 



^ Wait. 


, ... I 

... \ | Wait for MAC Save new (request) i / / 
Mime J.... management to signals while awaiting }---/ ' 

J i process request. response from MLME. i / / 




MlmeAuthen_ X 
ticate. confirm^ 
(sta.alg.sts) \^ 


MtmeDe 
enticate. 
firm(sta.s 


auth_ / 
,ts) \ 


I 1 7 

MlmeAs_ X 

sociate._ <^ 

confirm(sts) 


1 

MlmeReas. / 
sociate._ <^ 
confirm(sts) \^ 


i 1 7 

MlmeDis. S 

associate. _ <^ 
confirm (sts) 


MlmeScan._ / 
confirm ^ 
(bssSet.sts) \ 




<MlmeOis_ 
associate., 
confirm(sts) 



Scan leaves station 
in Idle state because 
synchronization with 
a previous Bss is lost. 
Implementations may 
save and restore TSF 
and association info 
to automatically re- 
join a previous Bss. 




(bss) 



(ap) 



( 633 ) ( " ) 




rqState:« ap, 

mActing_ 
As'AP:a true 



(true) 


(true) 


) 




rqState:* ibss 









export 
(mActing_ 
AsAP) 



IBSS 
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MMGT 



Block MLME.STA 



Signal 
Sta State 
(MacAddr.StationState) 



' In this block are the handlers K 
for Mime operation requests. ^ 
the responders for incoming 
management frames, and the 
time synchronization function 
for station operation, both 
as an associated station in 
an infrastructure 8SS or as 
a member of an IBSS. This 
block also contains the 
process which maintains 
record of power save mode 
and station state for access 
by other processes. V 



Mop 



Mime Associate, confirm. 
M I meAuthenticate. confirm. 
MlmeDeauthenticate.confirm. 
MlmeDisassoaate. confirm. 
MlmeJoin.confirm. 
MtmePowermgt.confirm. 
MtmeReassociate. confirm. 
MlmeScan. confirm. 
MlmeStart. confirm. 
MlmeAuthenticate. indication, 
MlmeOeau then ticate. indication. 
MlmeOisassoci ate. indication 



MLME_1a(1) 



MtmeAssociate.request 
MlmeAuthenticate. request. 
MlmeOeau then ticate. request 
MlmeOisassoci ate. request. 
M I meJoin. request. 
M tmePo wermgt.request. 
MlmeReassociate. request 
MlmeScan. request, 
M I meStart. requ est 



MM 
TX 



i This process assumes 
- \ that the Mime request 
i signals have been 
I validated by MAC 
i Management service. 



MC 
TL 




PS 
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Process Power _ Save. Monitor 



ps_momtorJa(2) 



/* This process j\ 
records power ^ 
save state as 
indicated in the 
headers of all 
valid rx frames: 
and auth/asoc 
state from all 
management 
exchanges by 
this station. */ 



/* Each of these sets holds MAC addresses of [\ 
stations with a particular operational state. ^ 
Stations are added to and removed from sets 
due to MLME requests, received management 
frames, and bits tn received MAC headers. 
Sets are not aged, as there is no requirement 
for penodic activity, but aging to expunge 
addresses of inactive stations is permitted. 

7 del 

awake. /* detected in sta_active mode V 
asleep. /* detected in power_save mode 7 
authOs, /* authenticated by open system 7 
authKey. r authenticated by any other alg. V 
asoc r associated (0|1 member. non-AP) V 
MacAddrSet : 



del psm 

PsMode : 
del psquery 

Boolean : 
del sst. asst 

StationState 
del sta 

MacAddr : 



Clear specific 
authentication 
mfo at startup 
but not reset. 



CD 



authOs:=empty. 
authKey:=empty 



' Power Save Mode and 
J— j Station State monitoring 
i here, query on next page. 



T 



asoc:= 


! empty 






awake:=empty. 
asleep;sempty 







' Clear info on 
- \ power save and 
> associated 
! stations at 
J startup and 
! at reset. 




Deauthenticate 
of associated 
station causes 
disassociate 
at same time. 
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Process Power, Save Monitor 

ps.monitor_2a(2) 



Momtorjdle 



I Power Save and Station Slate 
- *, query and response below, 
i monitoring on previous page. 



Pslnquiry 
(sta) 



j Pslnquiry returns Ps Response to 
- report power mode awake, asleep, 
i or unknown at the target station. 





[ Sslnquiry returns SsResponse to report 
station state not.auth. assoc. or dis_assoc: 
[ and authentication state not_auth. 
, auth.open. or auth.key at the target station. 



(false) 



<PsResponse 
(sta. psm) 
to sender 



(true) 



asst» 
auth.open 









(true) 


as St * 




auth_key 






sta in 
asoc 



(true) 



(true) 



sst:= 
asoc 



3: 



(false) 



(false) 



assta 
not_auth 



sst:» asst 



• When there is no association 
--•(info, station state is identical 
i to authentication state. 



SsResponse 
(sta.sstasst) 
to sender 
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Mop 



Process M(me_Sta_ Services 



Mtme Authenticate .con firm, 1 
MlmeDeauthenticate.confirm | 



T 



sta_Mm_svc_1b(2) 



Signal Atim( Frame), TV 
AsocReq(Frame), ^ 
AsocRsp( Frame). 
AuthEven( Frame). 
Autfi Odd (Frame), 
Beacon(Frame.Time.Time). 
Cfend. 

Cls2err(MacAddr), 
Cls3err(MacAddr). 
Deauth( Frame), 
Disasoc(Frame). 
ProbeReq{Frame). 
P robe Rsp( F ra me . Ti m e. 

Time), 
ReasocReq (Frame). 
ReasocRsp(Frame), 
Send(Frame.lmed). 
Sent(Frame.TxStatus). 
Sst(MacAddr. 

StationState). 
Xpert ; 



/* Each of these ovals represents a N 
SERVICE. Each service contains ^ 
the state transitions to handle a 
(DISJOINT SUBSET of the input 
signal set of this process. Services 
share local variables and the input 
queue. At any instant, a state 
transition can occur in, at most, one 
service - the service which handles 
the kind of signal at the head of the 
process input queue. V 



[AuthEven. 1 
Cls2err / AuthReqService_ 




MlmeAssociate.confirm. 
MlmeDisassociate. confirm. 
MlmeOisassooate. indication. 
MlmeReassooate. confirm 



[MlmeAuthenticate.indication. 1 
M tmeDea uth en ticate. indication 



Mime Join, confirm, 
MlmePowermgt. con firm. 
M I meScan. confirm. 
MlmeStart. confirm 



ArqMop 



MlmeAuthenticate.request. 
MlmeDeauthenticate. request 



As Mop 



MlmeAssociate. request 
MlmeReassociate. request 
MlmeOisassooate. request 



SyMop 



Doze, Wake. 
MmCancel. 
SwChni. Tbtt 



M ImeJ oin . req uest. 
M ImePowermgt. request. 
MlmeScan. request. 
MlmeStart. request 



ToRx 
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Process Mlme.Sla. Services 



sta_Mm_svc.l.la(2) 



Timer Tasoc 
Tauth. Tchal. 
Tbcn. Tatim 



/* Intra-MAC remote vanables V N 
del exported L_ 
dotllPowerManagementMode PwrSave:= sta_actve, 
dot1 1 DesiredSsid Octetstnng, 
do 1 1 1 D esi red B ss Ty pe. 

dot11 Ope rational RateSet Ratestring:s mkOS(2.1). 

dot11BeaconPenod TU. 

dotnDtimPeriod Integer:^ 1. 

dot11AssoaationResponseTirneOut TU. 

mAld Asodd:= 0. 

mAssoc Boolean:* false. 

mAtimW Boolean := false. 

mBrates Ratestring:smkOS(2.1), 

mBssId MacAddr:* nullAddr. 

mCap Octetstring:^ 02. 

mCfp Boo lean := false. 

mOisable Boolean: = true. 

mDbmCount Integers 1. 

mlbss Boolean:* false. 

mNexlBdry Time:= 0. 

mNextTbtt Time:* 0. 

mPcAvail Boot ean:= false. 

mPcPoll Boolean:* false. 

mPdly Usec:*0. 

mPss Ps States awake. 

mSsId Octetstnng:* null: 
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Service Distribute _Mmpd us 



mmpdu_svc_ la{2) 



Re-export the 
intra-MAC 
remote 
variables to 
make updates 
available. 



CD 





export( 
mAld. 
mAssoc. 




mAtimW. mBssld. mCap.mCfp. 
mOisable. mlbss. mListenlnt. 
mNextBdry. mNextTbtt. mPcAvatl. 
mPcDIvr. mPcPoll. dot11Power_ 
ManagementMode. mPss. mSsfd) 






' Mmpdu \ 
Idle 





/* This service routes K 
mmpdu and station state- 
update signals from and 
to the mime operational 
services. Signals are 
not modified, but some 
superfluous parameters 
are omitted in transfer. 7 











\^ Send 

^(mSpdu. 
/ mlm) 






'mRate:= 
data rate to 
send mmpdu' 






X MmRequest 
^ (mSpdu. 
\mlm.mRate) 


s. 






Mmlndicate 

(mRpdu.mtE. 

mtT.mSerr) 



ftype 

(mSpdu^ 

beacon. 
probe_rsp) 




i MmConfirm only 
- -J needed for probe 
■ responses and 
! beacons. 



The selection criteria for 
Mmpdu Tx data rate are 
not specified. Frames 
to group addresses must 
use one of the basic rates. 
Requests should use one of 
the basic rates unless the 
operational rates of the 
recipient station are known. 
Responses must use a basic 
rate or the rate at which 
the request was received. 



del mAdr MacAddr ; 
del mlm Imed ; 
del pri Cf Priority : 
del mRate Rate ; 
del mRpdu, mSpdu Frame 
del mSerr StateErr ; 
del mSst StationState : 
del mtE. mtT Time : 
del mTxstat TxStatus : 
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Service Distribute.Mmpdus 

mmp<Ju_svc_l.ib(2) 



(cfend. cfend _ack) 







/ Cfend 









Mmpdu 
Idle 



Mmpdu_ 
Idle 



] 





(0) 


AuthEven 




(mRpdu) 


< 



mTst:= mod( 
authSeqNum 
(mRpdu). 2) 




AuthOdd 
(mRpdu) 



(atim) 



Atim 
(mRpdu) 



(beacon) 



Beacon 
{mRpdu, 
mtE.mtT) 



(reasoc.req) 



X 



ReasocReq 
(mRpdu) 



(probe_req) 
I 



ProbeRoq 
(mRpdu) 



(disasoc) 



Oisasoc 
(mRpdu) 



(class3) 




(reasoc.rsp) 

1 



ReasocRsp 
(mRpdu) 



(probe_rsp) 



ProbeRsp 

(mRpdu. 

mtE.mtT) 



(deauth) 

2 



Oeautn 
(mRpdu) 



Mmpdu 
Idle 
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Service AuthReqService_Sta 



auth_req_ia(2) 



Auth_Req_ 
.Idle 



| Authenticate Request is on 
— - t this page. Deauthenticate 



del auAig AuthType : f\ 
del auCap Capability : L 
dcl auRdu. auSdu Frame : 
del auRsn ReasonCode : 
dci auSta MacAoar : 
del auSts TxResult : 
del auTmot Kusec : 









\. MtmeAu, 




(auSta. 


ythenticate... 




auAlg. 


/ request 




auTmot) 



/* This service handles |\ 
(De)Authenticate requests. 
This service also handles 
incoming the generation of 
responses for class 2 errors. 

This state machine handles 
Mime requests sequentially, 
which is the simplest case. 
It is permissible to have 
several authentications in 
progress at once, provided 
the destination stations are 
all different. To support 
concurrent sequences this 
state machine gets collapsed 
into one state, with sequence 
state held in a variable. The 
local variables are replicated 
for each sequence, selected 
by responder address. V 




i Ignore response 
{ sequence errors, 
i which may be from 
| requests that timed out. 
i Also, there is no 
| status in odd to inform 
, the sender. 
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Service AuthReqService.Sta 



Auth_Req_ 
Idle 



Cls2err 
(auSta) 



J Deauthenticate request and 
• class 2 error are on this page, 
i Authentication on previous page. 



IL 



aeauth_2at2) 



\^ MlmeOeau_ 




(auSta. 


^thenticate._ 




/ request 




auRsn) 



asRsn;s 
class2_err ■ 



i 1 

auSta. 
mBssid. 
auRsn) 



auSdu:^ 
mkFrame 
(deauth. 



Send \^ i Send notification. 

(auSdu. \ - - -] do not wait for 

norm) / i delivery confirmation. 



S$t(asSta. 
de^auth) 



| Update local stations state 
■-, records. Sending deauth also 
i clears asoc state if present 



If deauthenticating 
the current AP. or 
deauthenticating 
everyone, end the 
association (if 
any) by clearing 
mBssid and m Assoc. J 
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Service AsocService_Sla 



sta_dtsasoc_1a(3) 



/* This service handles 
Associate. Reassociate and 
Disassociate requests at non- 
AP stations. This service 
also generates responses for 
class 3 errors and incoming 
(re)assoaation requests. V 



del asCap Capability : N 
del asRsn ReasonCode ~ 
del asSta MacAddr : 
del asSts TxResull : 
del asTrrtot Ksjsec : 
del asRdu. asSdu Frame 



Asoc_ldle 



j On this page are Disassociate request incoming 
- - t Oisassoaation frame, class 3 error, and incoming 
i (Re)Association request frames. More on next page. 




AsocReq 
(asRdu) 



(false) 



(false) 



X 



ReasocReq 
(asRdu) 



Cls3err 
(asSta) 



MlmeDis_ 
associate., 
request 



asRsn:* 
class3_err 



(true) 



(asSta. 
asRsn) 



asSdu:= 
mkFrame 
(disasoc. 



LZJ 



MlmeDis_ 
associate., 
indication 



(addr2(asRdu). 
rea so n(asRdu)) 



> Ignore incoming 
- \ association frames 
i at non-AP station, 
j and disassociabon 
' frames from all 
j but current AP. 



asSta. 

mBssid. 

asRsn) 



Send 




(asSdu, 




norm) 








Sst(asSta. 


dis.asoc) 



Sst(asSta, 
dis_asoc). 



j Update station 
state regarding 
i this association. 



i Local station state 
•J updated even if 
• notification frame 
i is undeliverable. 

< If destination 
1 is the current 
' AP clear mBssid 
J and mAssoc. 



mAssoc:=false. 
mBssid: = 
nullAddr 



Xport 



CZD 
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Service AsocService Sta 



sta.asoc.2b(3) 



JZ 



Mlme_ 

Associate., 

request 



(asSta. 
asTmot. 
asCap) 



dot 1 1 Assoc. 
itationResponse, 
Timeout= as Tmot 



export(dotll_ 
AssociationRe. 
sponseTimeOut) 



asSdu:= 
mk Frame 
{asoc_req. 



set(now + 
dKusec(as_ 
Tmot).Tasoc) 



asSta. 
mBssid. 
(asCap // 
mkOsfmLis 
tenlnt.2)// ~ 
mkElem 
(eSsld.mSsid) 
// mkElem 
(eSupRates. 
mBrates)) ) 



Send 

(asSdu. 

norm) 



| On this page are as so a ate request 
■ - ( and reassociate request. More 
t of this state on previous page. 




MlmeRe_ 

associate,. 

request 



(asSta. 
asTmot. 
asCap) 



dot1 1 Assoc, 
itationResponse. 
TimeOut:»asTmo1 



export(dot11_ 
AssociationRe_ 
sponseTimeOut) 



asSdu:= 
mkFrame 
{reasoc _req. 



set(now + 
dKusec(as_ 
Tmot).Tasoc) 



Send 

(asSdu. 

norm) 



asSta. 
mBssid. 
(asCap // 
mkOS(mLis_ 
tenlnt.2) // 
mBssid It 
mkElem 
(eSsld.mSsid) 
// mkElem 
(eSupRates. 
mBrates)) ) 



Wart_ 
_Reasoc_ 









1 


/ • / 


Reasoc / \ - 
Rsp(asRdu) V >'asoc 
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Service AsocService_Sta 



sta_asoc_2.1a(3) 



Remove old 
association 
before saving 
data on new 
association. 




resat(Tasoc) 



mCap:= 
CapA(asRdu) 



if (mCap and 
cPollable)=cPollable 
then true else false fi 



mPcAvail:= 
mPcPoll or 



if (mCap and 
cPollReq)=cPollReq 
then true else false fi 



mAldiB 
Ald(asRdu) 



dot1 1 0pera1_ 
ionalRateSets 



getElemfasRdu. 
eSupRates) 



mBssid:= 
addr2(asRdu) 



mAsoc:= 
true 



Re-export 
intra- MAC 
variables. 



Xport 



Asoc _ I die 
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Service AuthRspService 



auth.rsp_ib(2) 



Auth Rsp 
.Idle 



Tchal 



del arAlg. arAlg2 AuthType : K 

del arRdu. auSdu Frame : *A 

del arRsn ReasonCode : 

del arSeq. arSeq2 Integer : 

del arSta. arSta2. arSta3 MacAddr : 

del arSC StatusCode ; 



AuthOdd 
(arRdu) 



/* Key to generate 
challenge text V 
del chKey Odetstring 



arSeqts 
authSeqNum 
(arRdu). 




arAlg: = 

authAlg 

(arRdu), 

arSta:= 

addr2 

(arRdu) 



arSeq 



arSC:» 
auth_seq_ 
Jail 



T 



/" The RC4 PRNG is accessed |\ 
as a remote procedure: ^ 
prnString:* call RC4{key.length) 
This procedure only present when 
dot11PrivacyOption_ 
Implement8d=true 
V 

imported procedure RC4 ; 
fpar PmgKey, Integer : 
returns Octetstring : 



/' This service handles 
incoming Authentication 
& Oeau then t tea tion frames. 

This state machine handles 
only a single shared key 
authentication challenge 
sequence at one time, which 
is the simplest case. It is 
possible to have several 
authentication responses in 
progress at once, provided 
the source stations are all 
different. To allow multiple 
responses this state machine 
gets collapsed into one state, 
with sequence state held in a 
vanable. The local variables 
are replicated for each 
response, selected by 
requester station address. V 



import 

(dot11Authenti_ 
cationAlgonthms) 




imported dot1 lAuthenticabonResponse. 
Timeout Kusec ; 



3 



Optionl mplemented 



Sst(arSta. 
de.auth) 



arSdu:« 
mkFrame 
(auth.arSta. 



arSdu:« 
mkFram* 
(auth. arSta. 



Send 

(arSdu. 

norm) 



mBsstd. 
(arAlg// 
mkOS 
(arS©a*1.2) 



Send 

(arSdu, 
norm) 



mBssid. 
(arAlg // 
mkOS(2.2) // 
successful // 
mkElem(eCtxt 
arChalng))) 



■ The chKey value used to 
\ generate challenge text is 
i arbitrary, and does not need 
| to be shared. However. 
> implementers are advised 
] that the source of chKey 
• SHOULD NOT be one 
) of the WEP keys, because 
< the output of the PRNG 
| when using chKey is sent. 
' unencrypted, in the 
! challenge text field. 



set(now* 
(import( 



Auth Rsp_ 
.Idle 



dod 1 Authentication _ 
ResponeTimeout)). Tchal) 



Wait_Chal_ 
_Rsp 



i Set response timeout and 
*> await response to challenge. 
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Service AuthRspService 



auth_rsp_2b(2) 



Watt_Chal_ 
_Rsp 




In the case of 
undecryptable 
response, assume; 
Auth frame from 
expected source 
is sequence 3. 



Timeout while 
waiting is a 
failed attempt. 



AuthOdd 
{arRdu) 



Tchal 



arSeq2:= 
authSeqNum 
(arRdu). 



i Update station 
i state, deauth 
i clears asoc 
! if present. 



(arSta3, 
reason 
(arRdu)) 



mAssoc:=fatse. 
mBssid:^ 
nullAddr 



> If deauth is 
.J from current 
i AP. end asoc 
| (if any) by 
] clearing 
j mBssid and 
i m Assoc. 



Xport 





arSta2:= 

addr2 

(arRdu) 



SstfarSta. 
de_auth) 



arSeq2 
else 



(false) 



(true) 




Auth Rsp_ 
Jdle 



• Open_system 
\ request from a 
> different station 
[ can be handled 
i while awaiting 
| challenge rsp. 



importfdotl 1AuthentL 
cationAlgonthms) 



arSC;s 
unspec_fail 



T 



arSC:=> 
chnlg_fail 




-l^<^ arChalngs " 
(false) 

7 (true) 



getElem 

(eCtxt 

arRdu) 



arSC:= 
successful 



Sst(arSta2. 
de_auth) 



Sst(arSta2. 
auth.key) 



arSdu:" 
mkFrame 
(auth. arSta, 



mBssid. 
(arAJg // 
mkOS(4,2) 
// arSC)) 



arSC:= 
unsupt_alg 




arSC:= 
successful 


} 






Sst(arSta2, \ 
de_auth) ? 


Sst(arSta. \ 
auth_open) ? 






1 


( 




arSdu:= 
mkFrame 
(auth.arSta2. 




mBssid. 

(authAlg 

(arRdu)) 

// mkOS 

(arSeq2+1. 

2) // 

arSC)) 








Send \ 
(arSdu. \ 
norm) / 




^ 





Send 

(arSdu, 

norm) 



Wait_Chal_ 
_Rsp 



• Continue 
ito watt for 
i response to 
| challenge. 



A station 
is allowed 
to reject an 
open system 
auth request 
with status 
un spec Jail. 



Auth Rsp_ 
Jdle 
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Service Synchronization_Sta 



sta_Powermgt_lc(8) 



del yAttmRx. yPsm. yRdtim. yWake Boolean : 

del yAtw. yBcn. yEnr. yMocp. yStt Time ; 

del yBcnPenod. yOtim. yemax, yemm Kusec : 

del ybd BssOscr : 

del ybdset BssDscrSet : 

del ybtp BssType : 

del yosid MacAddr : 

del yctist Intstring : 

del ycx. yjto. ytemp Integer : 

del yOspm OsParms ; 

del yFhpm FhParms : 

del ylbpm IbssParms : 

del ypdly Usee : 



del yPhpm PhyParms : N 
del yRdu. yTdu Frame 
del yssid Octetstrmg : 
del yOrates Ratestnng: 
del ystp Scan Type : 
del ytrsl TxResult : 



timer Tscan. 
Tmocp. Tpdly 1 



vanables 




to default 




values' 






Set TSF 


i 


time to 


r 


zero. 


i 



No_Bss. Bss, 
Ibss.Active, 
lbss_ldle 



^R esetMAC 



PsmDone 



'obtain Phy 
characteristics* 



/ not \ 
\ mOisable X 



i PsmDone sent 
- \ by TxCoord 
i after change 
j in power save 
i indication is 
[ announced in 
\ frame exchange. 



reset all 
intra-MAC 
remote 



MlmePower, 
mgl.confirm 
(success) 



ytemp:* 
call TSF 
(0, true) 



Xport 



Setting these 
timers to now 
causes events 
in each of the 
multi-state 
services of the 
process, forcing 
each service to 
its idle stale. 



> 



Wake 



reset(Tbcn), 
reset(Tatim). 



set(now.Tasoc), 
set(now.Tauth). 
set(nol.Tchal) 



dot1 1 Power 
rtfanagementMode^ 
yPsm 



No.BSS 



1 PowerMgt requests 
--| valid in all 
i top-level states. 









\ M!me_ 
\ PowerMgt. 
/ request 




(yPsm. 
yWake. 
yRdtim) 








mReceive_ 
Dtims:= 
yRdtim' 






(mPss = Doze)) 
or {(yPsm = 
station_active) 
and (dot11PowerMan_ 
agementMode - 
power, save)) 



Xport 



Copyright © 1999 IEEE. All rights reserved. 



379 



1S0/IEC 8802-11: 1999 (E) 
ANSI/IEEE 802.11. 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



Service Synchronization_Sta 



sta_Scan_2d{8) 



No.Bss. Bss. 
Ibss.Active. 
Ibssjdle 



1 Scan requests 
- \ valid m all 
i top-level states. 









\. MtmeScan._ 




yssid, ystp. 


^ request^ 




ypdly. yclist 


/ ybtp.ybsid. 




ycmin, ycmax) 



Only accept 
Scan request 
when no frame 
exchange is 
in progress. 



k 





(false) 


/ MlmeScan._ 
\ confirm ( 




empty. in valid) 










\ 1 No loss sync 
I- - - -j if scan parms 
^ / i are invalid. 



(a divers can) 





bcstAddr, ytosid, 

mkElem(eSsld, 

ySsid)//mkElem( 

eSupRates, 

dot1 1 0perat. 

ionalRateSet)) 



I chnl J 
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Service Synchronization. Sta 



sta. Scan .2.1 b(8) 



Act, Listen. 
Act_Receive. 
Pa s_ Listen 



[ chnl J 



Beacon 

(yrdu.yrend. 

ytstr) 



ZL 



ProbeRsp 

(yrdu.yrend. 

ytstr) 



[ Act_Receive. \ 
\ Pas, Listen j 



'ybd:= bss 
descnption 
info from yrdu' 









Tscan / 


1 ) 








ycx:= 
ycx ♦ 1 



ybd!bd_ 
StartTsrs 
ytstr 



ybdset:* 
ybdset 
or ybd 





(false) 


SwChnl 




(yclist(ycx). > 


true) 





(active_scan) 



(Wait.Csw. \ 
,Oone I 





filter ybdset 
for ybtype 
and duplicates' 



ystype 

M [passive, scan) 



< 



MlmeScan., 
confirm( 



Set 
(now+ycmax. 
Tscan) 



ybdset. success) 



No.Bss 



SwOone 


<^ ^ Pas, Listen ^ 






set 

(now*ypdry. 
Tscan) 


' Set probe 
■---j delay 
i timeout. 



■ Scan ends in 
-.J No _ Bss state 
i since sync lost 
[ with prior Bss. 
i Implementations 
| may save/restore 
i TSF and asoc 
[ info to re-join 
i prior Bss. 



Listen for 
activity 
on channel. 



Act. Listen j 



3k_ 



Wart_Probe_ 
.Delay 



Tscan 




/ / import \ 
\ \ (mRxA) / 



Set 
(now*ycmax, 
Tscan) 



< Go to next 
\ channel if 
• no activity 
! by min time. 



| Set probe 
■■[response 
i (max) timeout. 



r / Act. Receive V ■ 



, 1 Receive 
v \ responses 
i on channel. 









Tscan f 






Send \v 
(tpdu.imed) / 






Set 
(now*ycmim. 
Tscan) 


> 





1 Transmit 
-■[probe 
i request. 



< Set channel 
* -[ activity 
i (min) timeout 



Act.Listen 
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Service Synchronization _Sta 



sta_StartJbss_3c(8) 



'Start IBSS on 
-j this page, join 
i on next page. 



yBcnPenod. 
yOtim. /* cfpm '/. 
yPhpm. ylbpm. 
ypdly. mCap. 
mBrates. yOrates) 




3k. 



AP_Active 



• Activate 
•[ AP state 
i machine. 



dot1 1 OtimPenod:» 
yDtim.dot110per_ 
ationa I R ateSet: =yO rates 



exporl(dot1l_ 
BeaconPenod. 
dotl 1 0timPeiiod. 



dot11 Operational, 
RateSet) 



yBcn:= 
hUsoc 
(yBcnPeriod) 



yAtvr=kUsec 
(atimWin 
(ylbpm)) 



set actual 
phy parameters 
from phpm' 



Xport 




Wait probe 
delay before 
initiating a 
transmission. 



Init.WaiL 
_ Pro be Del ay 




yMocp:=kUsec 
(dwellTime 
(yFhpm)) 



mNextBdry:= 
now*(yMocp 
- (call TSF 



set 

(mNextBdry. 
Tmocp) 



'yChan:= 
first (or only) 
channel* 



SwChnl 
(yChan.true) 



mNextTbtt:* 
now*(yBcn 
- (call TSF 



set 
(mNextTbtt. 
Tbcn) 



mlbss:s true, 
mDisable:° 
false 



Xport 







I 


^>Tpdry 


• 







1 Start out as 
■\ Ibss probe 
i res ponder. 



<MlmeStart._ 
confirm 
(success) 



set(now ♦ 
tUsec(ypdly), 
Tpdly) 



(O.false) 
mod yMocp)) 



_ i Initialize 
" dwell timer. 



i Set starting 
-^channel (FH) 
i or operating 
| channel (DS). 
t null for IR. 



(O.false) 
mod yBcn)) 



j Initialize 
" beacon timer. 



382 



Copyright © 1999 IEEE. All rights reserved. 



MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS 



ISO/IEC 8802-11: 1999 (E) 
ANSI/IEEE 802.1 1, 1999 Edition 



Service Synchronization. Sta 



No.Bss 





(false) 


/ MlmeJoin.. 
. confirm 
(invalid) 






/ 


No.Bss j 



T 



Join.Wart. 
.Beacon 




mBssld:=ybd!_ 
bdBssld.mSsld:= 
ybd'bdSsld. 



yBcn:=kUsec( 
ybd'bdBcnPer). 
dol11DtimPeriod 



ycfpm:=ybd!bd_ 
CfParms, ytbpm:: 
ybdlbdlbParms, 



dot1 1 0per_ 
atonal RateSet:» 
yOrates 



export(dotll_ 
BeaconPeriod. 
dotllDtimPeriod, 



set 

(now ♦ yBcn, 
Tbcn) 



Xport 



select channel 
of target Bss' 



ytemp:* 




ytodl. 


call TSF( 




bdStartTs), 


(now* 




true) 



sta_Jom_4c(8) 



' Join on this 
--[ page. Start on 
i previous page 



^ Join. Wait. 8cn^ 









1 


ypdly. yOrates) 


Tbcn <^ 


Beacon / 

ysti) \ 



j A probe response from 
1 the bss/ibss can also be 
i used to establish sync. 




mCap:= ybd!_ 
bdCap.mBrates:= 
ybdlbdRates. 

mPdly:=ypdty 



dot110per. 
ration alRateSet) 



X MlmeJoin._ 
^ confirm 
\^ (timeout) 






mBssId:-* 
nullAddr, 
mSsld:=null 




f 



yMocp:=kUsec 
(dwellTime 
(yFhpm)) 



mNextBdry:= 
now+fyMocp 
- (call TSF 



(0, false) 
mod yMocp)) 



set 

(mNextBdry. 
Tmocp) 



No.Bss 



_i Initialize 
" *' dwell timer. 



yChan:= 
first (or onty) 
channeT 



i Set starting 
channel (FH) 
i or operating 
1 channel (DS), 
\ null for IR 



SwChnl 
(yC nan, true) 





else 


m Disable: » 

false, 
mlbs3:=false 








Xport ^ 







m Disables 

false, 
mlbss:= true 



Xport 



^ Bss ^ ^ Ibssjdle ^ 



mNextTbtt:- 
now* (yBcn 
- (call TSF 



(O.false) 
mod yBcn)) 



set 
(mNexlTbtt, 
Tbcn) 



_ j Initialize 

" ' beacon timer. 



<MlmeSlart._ 
confirm 
(success) 
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Service Synchronization_Sla 



sta_TSF_lbss.5a(8l 



Tbcn 



set 
(now+yBcn. 
Tbcn) 



Wake, 
TBTT 



ytdu:* 
mkFrame 
(beacon, 



mAtimW:=tnje, 
yAtimRx:sfalse. 
mPss:=awake 



Xport. 
Send 

(ytdu.imed) 



set 

(now+atimWin 
(yfbpm).Tatim) 



I bss_ Active. 
Ibssjdle 



1 States when pined/started Ibss. 
■-[ lbss_ Active when sent beacon this 
i interval so respond to probe requests. 



Atim 
(yrdu) 


< 






yAtirr 
tn 


iRx:= 
je 



Tatim 



bcstAddr, 
mBssId, 08 
P timestamp 

inserted 

during tx V 
// mk2octets 

(yBcnPenod) 
// mCap 
// mkElem 

(eSsld. 

mSstd) 
// mkElem 

(eSupRates. 
dot11 Operational 
RateSet) 
// mkElem 

(ePhpm, 

yPhpm) 
// mkElem 

(elbss. 

ylbpm)) 




and (not yAtimRx) 
and jytrsl 
/s successful) 



adopt 
values 
from yrdu' 



MmCancel 



ytemp:= 
call TSF 



(tstamp(yrdu) 
+ (now - yStt), 
true) 



Xport 
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Service Synchromzation_Sta 



sta_TSF_bss.6a(8) 



Tbcn 



set 

{now+yBcn. 
Tbcn) 



mDtim_ 
Count 3 




mDtim_ 
Count 



(=0) 



yLicnt:= 



mPss;* 
awake 



Wake 




Bss 



1 State when joined Bss. receive 
•, beacons, ignore probe requests, 
i adjust TSF to track AP's time. 



Cfend 



<mCfp and 
(now >= 



import{ 
mNavEnd)) 



Beacon 
(yrdu. 
yEnr. yStt) 



mCfp:s false 



if mDtimCount=0 
then 

dotHDtimPerkxl-1 
else 

mOtimCount-1 fi 





if CfpCount( 
yCfpm)«0 
then CfpPenod( 
yCfpm)-1 
else CfpCount( 
yCfpm)-1 fi) 



(CfpMaxDur 

(yCfpm), 

cfp.bss) 



if yLicnt=0 
then yLmt-1 
else yLicnt-1 fi 




power. save) and 
(yUcnt»0) 
and (import 
(mReceiveOtims)) 



(m Bss Id : 



Xport 



addr2(yrdu)) and 
(mSsld=getElem 
(eSsld. yrdu)) 



J (true) 


vb (false) 


'adopt 
values 
from yrdu" 










ytemp:= 
call TSF 




(tstamp(yrdu) 
♦ (now - yStt). 
true) 








mCfp:= if 
cfpDurRem 
(yCfpm) > 0 




then true 
else false fi 




{power, save) 



mPss:** 
awake 




Doze 

' r— 










> 



Bss 
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RX 



PS 



Block Reception 



Includes decryption if 
dot1 1 PrivacyOption Implemented 
=true. This is a typical 
location, but implemented 
may use other locations 
between the PHY_SAP_RX 
and MAC. SAP as long as 
they provide the specified 
behavior as observed at 
LLC. MLME and the WM. 



/* This block handles octet-level [\ 
reception of MPOUs from the ^ 
PHY. and validation, filtenng, 
and decryption needed so higher 
blocks have uniform, error-free 
information from the relevant nc 
events. This block also maintains 
the MACs view of channel state, 
including the NAV (and remote 
variable mNavEnd). rx activity 
(and the remote variable mRxA), 
and slot timing (providing the 
Busy. Idle and Slot signals to 
the Transmission block). V 



^Busy, 



Idle, Slot 



PhyCca. indication, 1 
PhyCcarstconfirm 



signal ClearNav(NavSrc). N 
RtsTimeout 

RxMpdu(Frame. Time, Time, 

Rate.Bootun, 

KeyVector.KftyMapArray). 
SetNavfTim* 

Duration .NavSrc), 
UseO(f3(Tim«). 
UseEH3(Ttm«): 




receive, la(l) 



ToPs 



PhyRxStart.indication. 
PhyRxEnd.indication. 
PhyOata. indication 



^PhyCcarst.requestj 



PHY.SAP.RX 
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Process Channel.State 



nav_ciear_1b(2) 



(\ del exported K timer Tifs : K 
] tNavEnd as ttmer Tnav : M 

J mNavEnd Time : timer Tslot : 



ResetMAC 



dSifs:= 
dUsec 
(aSifsTime), 



dSlot:= 
dUsec 
(aSlotTime), 



dEifs:* 
dUsec 
(aSifsTime h 



dRxTx:=dUsec 

(aRxTxTurn_ 

aroundTimej^ 



dDifs:=dSifs ♦ 
(2 * dSlot) 



dlfs:= 
dEifs 



calcOur(first( 
import(mBrates)). 
stuff (aMpdu. 
Duration Factor. 
sAcxCtsLng) + 
aPlcpHdrLength 
* a Preamble. 
Length) ♦ dDifs) 



cs:= busy. 
tNavEnd:=0 



reset(Tnav) 



> Assume channel 
- \ busy until Phy 

• indicates idle. 
| tNavEnd is =0 

> until first rx 

! that sets Nav. 



PhyCcarst. 
request 



^ Cs_noNav ^ 



del cs CcaStatus : K 
del rxtx. slot, sifs Integer : ^ 
del dDifs. dEifs. dlfs. dNav. 

dRxTx. dSifs. dSlot Duration ; 
dci tNew. tRef. tRxEnd Time : 
del newSrc. curSrc NavSrc : 



| Eifs based 
-| on the lowest 
i basic rate. 



Wait IFS 
r IDLE V 



r 

/ not 
\ active(Tifs) 



> 



'ClearNav. RtsTimeout. 
- -| Tnav. Tslot ignored 
i in Wait. IFS state. 



Tifs 



Idle 



(idle) 



set 

(now+dSlot. 
Tslot) 



noCs noNav 
/* IDLE */ 



' Idle signal is 
\ sent at end of 
• the M2 interval 
| (Figure 47). 

' RtsTimeout 
-■I Tnav. ClearNav. 
1 Tifs ignored 
, in this state. 



SetNav 
>(tRef,dNav. 
curSrc) 




Tslot 



Slot 



set 
(now^dSlot 
Tslot) 



export 
(tNavEnd) 






noCs 


_Nav j 



SetNav 

(tRef.dNav. 

curSrc) 




set 

(tNavEnd, 
Tnav) 



set 
(now+dlfs. 
Tifs) 



export 
(tNavEnd) 



WartJFS 



i Slot signal is 
\ generated at 
' the and of each 
| M2 interval 
[(Fig. 47) while 
| channel is idle. 



Cs^Nav 



/* This process 
maintains chann. 
state based on 
both physical and 
virtual earner 
sense, generates 
slot time reference, 
and provides Susy. 
Idle & Slot signals 
to Transmission. 7 
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Process Channei.State 



nav_set.2c(2) 



noCs.Nav 
/* BUSY V 



1 Tstot and Tifs 
-\ ignored m 
tnoCs_Nav state. 



Cs.Nav 
/' BUSY '/ 



(busy) 



Cs.Nav 




Tnav 



1 Tslot and Tifs 
-•ignored m 
tCs.Nav state. 



PhyCca._ 
indication 
(cs) 



^^Tnay" 



PhyCcarst.. 
request 



curSrca 
nosrc 



(busy) 




(idle) 



PhyCcarst.. 
request 



noCs.Nav 



curSrc* 
nosrc 



set 
(now+drfs, 
Tifs) 



set 
(now+dlfs. 
Tifs) 



WaitJFS 



^ 

^ Cs.noNav ^ 



^ /* all states '/ ^ 









1 


UseEifs / 
(tRxEnd) 


UseDrfs / 
(tRxEnd) \^ 








dlfs:a 
dEifs-dRxTx 




dtfs:a 
dOifs-dRxTx 






1 


t 




set 

(tRxEnd+dlfs, 
Trfs) 


Clear NAV and 
use EIFS after 
channel change, i 










set(now.Tnav) 



■ The initial dMs tNavEnd is «0 1 

Rvalue is dEifs, until first m !- 

; set by a UseEifs on new channel. t 

[ signal generated * 

t by Validata.Mpdu 
] at startup and 
i due to ResetMAC. 



(false) 




(false) 







tNavEnd:" 
tNew. 
curSrcanewSrc 



T 



tNav£nd:«0, 
curSrc= nosrc 



Nav is cleared by setting Tnav > 
to now. This causes immediate \ 
Tnav signal to enable exit from 1 
noCs.Nav or Cs.Nav state. j 



tNavEnd := 
now, 
curSrc:»nosrc 



set(tNav£nd. 
Tnav) 



export 
(tNavEnd) 




Copyright © 1999 IEEE. All rights reserved. 



389 



1S0/IEC 8802-11: 1999 (E) 
ANSI/IEEE 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



Process Vahdate.MPDU 



start, nc_1b(2) 



Calculate PHY 
Rx delay that 
is subtracted 
from new to 
get reference 
point ttmes. 



D1:= dUsec 
(aRxRfDelay* 
aRxPlcpDelay) 



cErr=0. 
mRxA:*false 



export 
(cErr.mRxA) 



(Rxjdle) 



Reset MAC 



reset(Trts) 
1 



/* This process receives an MPDU from the [V 
PHY while calculating and checking the ^ 
FCS value. Frames with valid FCS. length 
and protocol version are sent for receive 
filtering, along with a snapshot of the WEP 
keys if dot11PnvacyOptionlmplemented=true. 

This process also provides Channel_State 
with Difs/Eifs and Rts timeout signals, 
and maintains the mRxA remote vanable. */ 



del exported mRxA Boolean:=false. K 

cErr as dot1 1 FcsErrorCount Counter32:= 0T 
imported mBrates Ratestring. 

dotllWepDefaurtKeys KeyVector. 

dot1 IWepKey Mappings KeyMapArray. 

dotl 1 ExcludeUnencrypted Boolean : 
timer Trts : 




del fes Crc : 
del D1. dRts Duration : 
del endRx startTs Time ; 
del k. rxLength Integer : 
del pdu Frame : 
del rxRate Rate ; 
del status PhyRxStat ; 
dctv Octet; 
del wDefautt KeyVector : 
del wKeyMap KeyMapArray 
del wExclude Boolean ; 




wKeyMap:= 
import^ 



wExclude: s 
import 



Rx_ Frame 



i Save copy of 
J WEP keys at 
i Rx Start in case 
| Mpdu is first 
i fragment of 
] encrypted 
, Msdu/Mmpdu. 



dotl1Wep_ 
Default Keys) 



dot11Wep_ 
KeyMap pings) 



(dotl! Exclude. 
Unencrypted) 
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Process Validate.MPOU 



validate _nt_2c( 2) 



i Save arrival time 
■J of first octet of 
• (what may be a) 
| timestamp field. 



(true) 



startTs:* 
now-01 



(false) 




| Save time of Rx 
•| end as reference 
i for start of IFS. 



( • ) 










PhyData. indicate 1 
ignored to drop [---■ 
excess octets, i 


PhyRxEnd._ / 
indication <^ 
(status) \ 






Save time of Rx > 
end as reference !- - - 
for start of IFS. i 


endRx:* 
now-01 




(true) 



cEm* 
inc(cErr) 



pdu:» substr 
(pdu. 0, 



exportfcErr) 



UseOifs 
(endRx) 



UseBfs 
(endRx) 



mRxA:«fais« 



Indicate thai 
reception is 
not in progress. 





(false) 




' RxMpdu 




startTs. 


(Pdu. 




rxRate. < 


endRx, 







expbrt(mRxA) 



i Erfs based 
-| on the lowest 
i basic rate. 
[ Assumed to 
i be the first 
j element of 
i mB rates. 



Rx.ldle 



dRts:=dUsec( 
(— | (2*aSifsTime)+ 
(2'aSlotTime)* 



T_ 



calcDur( rxRate. 
stuff(aMpdu_ 
Ou ration Factor. 
sAckCtsLng) ♦ 
aPtcpHdrtength + 
aP ream ble Length)) 



set 
(now*dRts, 
Trts) 



(nc Length - 
sCrcLng)) 



| Drop FCS field from 
i frame before passing 
i up for filtering. 




' RxMpdu 




startTs, rxRate. 


(pdu. 




wExclude.wDefault. 


endRx, 




wKeyMap) 
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Process Filter_MPDU 



prejilter_1d(4) 



dPsp:=dUsec( 
aSifsTime+calc_ 
Dur(first(import(" 




del exported cDud as dot1 IFrameDuplicateCount. 
cMc as dot1 IMulttcastReceivedFrameCount. 
cRx as dot 11 Received FragmentCount Counter32:= 0 



mBrates)). 

stuff{aMpduDuratton_ 
Factor. sAckCtsLng 
+ aPlcpHdrLength) 
+ aPreambieLength)) 



t Initialize tuple cache 
- \ for duplicate filtenng. 
' Cache capacity is set 
! by "tupleCacheSize" 
' but a specific size 
J is not specified. 



startTs.rxRate. 
wExclude. wOef ault, 
wKeyMap) 



imported mBrates Ratestnng. K 
mBssid MacAddr. "A 
mCfp Boolean. 

dot1 IGroupAddresses MacAddrSet. 
mlbss Boolean. 
mSsid Octetstnng. 
aStationld MacAddr: 



del cache TupleCache : \ 

del dup. myBss Boolean : ^ 

del dNav. dPsp, dAck Duration 

del endRx. strTs Time : 

del pdu Frame : 

del rxRate Rate : 

del sre NavSrc : 

del wDefaurt KeyVector ; 

del wExclude Boolean : 

del wKeyMap KeyMapArray ; 



dAck:= 
if (moreFrag 
(pdu) = 1) and 



Gather Power 
management 
info from all 
valid frames. 



(durtO(pdu) > 32767) 
then dUsecfdurid(pdu)) 
else 0 fi 









y Pstndicate 
<( (addr2(pdu). 




pwrmgt(pdu)) 








dNav: =dU sec 
(durld(pdu)), 
src:= misc 






i Non-AP. 
\ toOSsO to 
• accept frame, 
next page. 



_ j Frames with toDs=1 ignored by non-APs, 
" except Duration/Id field for Nav update. 



/* This process filters valid received K 
frames by destination address, and ^ 
Bssld for group destination addresses. 
This process also maintains received 
pdu counters and the tuple cache for 
detecting duplicated unicast frames. 

Data and management frames which 
need acknowledgement cause a 
NeedAck signal to ProtocoL Control 
as well as an RxMpdu to Defragment 
Piggybacked CfAcks cause RxCfack 
signals, and CfPolls cause RxCfpoll 
signals to Protocol .Control. If an 
RxCfPoll is sent for a Data+CfPoll 
or Data+CfPoll+CfAck, the NeedAck 
has to reach TxCoord dunng the Sifs. 
(The data frame report cannot serve 
this purpose because the payload may 
be a non-final fragment.) 

Duration and Cfp duration remaining 
are reported to Channel, State, and 
power save mode is reported to Mime. V 
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Process Filter.MPOU 



filter. sta_2b(4> 
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Process Filter_MPDU 



fiiter_ap,3a(4) 



All frames to 

AP are directed | 

except probe _req, i 



alse) 




i Receive probe 
\ request at AP 
» the same as at 
! Ibss station. 



import 
(dot1 1_ 
Mac Address) 



(false) 



(data.ack. 
cfend_ack. 
cfack) 



RxCfAck 
(addr2(pdu)) 



src:= if rts= 
ftype(pdu) then 
rts else src ft 




( probe _req) 



(beacon) 





<ClearNav 
(cfend_ 
Other) 

else 



SetNav 
(endRxdNav 
cfpOther) 



Nav to cover 
PS-Poll Ac* 
when DuriO 
field is SIO. 

Update Nav . 
using value 
in Duration/ID 
field of frames 
directed to all 
other stations. 
Else case is for 
Durtd=32768 
in the CF period. 




0- 



1 Unsolicited 
- -] RxCfAck signals 
t should not occur. 



1 Rx directed 
- -[ frame to AP. 
i next page. 



Filter. Idle 
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Process Filter_MPDU 



report_ot.4a(4) 



Count all valid 
directed frames 
to this sta. even 
those that will 
be discarded 
as duplicates 
or due to WEP. 




dup 
(true) 



cDup;a 
mc(cDup) 



export(cDup) 



Ps-Poll is on 
else path (as 
control frame) 
to allow ack 
or data as the 
response from 
protocol ctl. 




i Report incoming 
\ directed frames, 
i including all 
' received frames 
[ accepted at AP. 



cRx:= inc(cRx) 




cRx:= mc(cRx). 
cMc:= rnc(cMc) 



export(cRx) 



etryBtt 













(=1) 




(=0) 


dup:» 




searchTupleCache 
(cache. addr2(pdu). 
seq(pdu). frag(pdu)) 





(false) 



' Report incoming 
- -, group-addressed 
i frames at station. 



i Count all valid 
- - -j broadcast and 
i multicast frames 
| to this sta. even 
i those that will 
J be discarded 
i due to WEP. 



(cf end. 
cfend_ack) 



New cache entry 
if (addr2.seq) 
is not cached. 
If entry exists 
for (addrZseq). 
update time 
and fragment 
number of entry. 




startTs, 

rxRate. 

wExciude. 

wOefautt. 

wKeyMap) 



(data, management) 




/ Need Ack 

C (addr2{pdu), - 
\ endRx,dAck) 


j Directed Atim frames must 
■— , be acknowledged, but may be 
i omitted from cache, see 9.2.9. 






cache:« 


updateTupleCache 
— (cache. addr2(pdu). 
seq(pdu),frag(pdu) ( 
endRx) 


a 



^ Fittfjdle j 
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Process Defragment 



wep_ filter, ib(3) 



CD 




del exported clerr as dot1 WeplcvErrorCount. 
cUndc as dott IWepUndecryplableCount. 
cExcl as dot1 iWepExcludedCount Counter32:= 0 



dLife:= 
dUsec( 
import 



<dot11Max_ 
Receive, 
Lifetime)) 



imported mCfp Boolean ; 
imported dotllMaxReceiveLifetime Kusec : 
imported procedure RC4 ; fpar PrngKey. Integer : 
returns Octetstnng : 




auth) and 
authSeqNum 
(pdu)=3) and 
import{ 

dot1 1 Privacy. 

Option_ 

Implemented) 
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Process Defragment 



wep_decrypt_2b(3) 



Icrypt J 



Decrypt 




wMap. sKey_ 


(Pdu. 




MappmgLength. 


icvOk. 




wOefault) 




Authentication 
challenge resposnes 
with lev errors 
are reported, but 
Decrypt removes 
payload so Auth 
service is able 
to distinguish 
a bad key from 
a non-response. 
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Process Defragment 




[ Mpdu is not fragmented 
-, or defragmentation is 
t complete. 



buf:= 
ArAge 
(buf.now) 



(true) 



Rxlndicate 






(pdu.endRx, 




startTs.rxRate) 




(true) 



(true) 




i Msdu reception. 




k>0 
(true) 



arfree(buf) 



(false) 



buf(k)!inUse:« 
false 



buf(k)linUse:= 
true, 
buf(k)!rta:« 



buf(k)!rCur= 
fragNum(pdu), 
buf(k)!reol:= 



buf(k)) 
rsdu:=pdu. 






addr2(pdu). 




buf(k)!rsn;= 




seqNum(pdu) 






now + kUsec( 




import(do111_ 




MaxReceive. 




Lifetime)) 






keys(k)f 




wOefKeys:a 




wOefault. 




keys(k)l 




wKeyMap:= 




wMap, 




keys(k)! 




wExclude:* 




wExcl 



buf(k)!rCur= 
fragNum(pdu), 



(false) 




defragment_3c(3) 



1 Intermediate or 





(false) • 


final Mpdu of 
fragmented Msdu 


i Initial Mpdu 
— -J of fragmented 
i Msdu. Find free 
J buffer to begin 


k:= 
arSearch 
(buf. 




addr2(pdu). 

seqNum(pdu). 

fragNum(pdu)) 



(false) 

© 




length 

(buf(k)lrsdu) - 
sMacHdrLng) 
<= sMaxMsduLng 



buf(k)!rsdu:= 
buf(k)!rsdu // 
substrfpdu, 
sMacHdrLng, 
length (pdu)- 
sMacHdrtng) 
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Procedure Decrypt 



decrypt. 1 o(i) 



i : fpar i \ 

[ m/out pdu Frame. v * 
i in/out tcvOk Boolean. t 
j in map KeyMapArray. 1 
i m maplength | 
J KeyMapArrayLength, 
i in kvec Key Vector ; 




isWds:= 
toDs(pdu) and 
frOs(pdu) 



1 Test whether addr4 
- - -| field is present, 
i Only needed at AP. 



del icv Crc : 
del isWds Boolean : 
del decrypting, k. n Integer: 
del decryptSlr Octetstnng ; 
del key PmgKey : 
del kmap KeyMap : 



decryptLng:= 
length(pdu) - 
sMacHdrtng - 



sWepAddLng ♦ 

sCrcLng - if isWds 

then sWdsAddLng else 0 fi 





(true) 



kmap: a 




(addr2(pdu), 


keyLookup 




map, 

maplength) 





(true) 


key:* 




kmap! 




wepKey 






nullAddr 



if isWds then 
sWdsAddLng 
else 0 fi 



k:= 0. 
n:« 

sWepHdrtng - 



Decrypt by xor < 
of payload with ]- — 
decrypt string, i 



ICV test value ■ 
calculated from [• - - 
decrypted data, i 



pdu(n):= 
pdu(n) xor 
decry ptStr(k) 



icv:= crc32 
(icv. pdu(n)) 



key:= kvec 
(keyld(pdu)) 



■Use default key 
selected by 
i keyld value. 




Use RC4 PRNG 
to generate an 
decrypt stnng 
as long as the 
MPDU payload 
plus the ICV 
field. 



" Remove ICV 
\ and IV fields 
' from MPDU. 
] report decrypt 

• success if ICV 
! result correct 

• or selected 

! key value null. 



Copyright© 1999 IEEE. All rights reserved. 



399 



ISO/IEC 8802-11:1999 (E) 
ANSI/IEEE 802.11, 1999 Edition 



LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 



C.4 State machines for MAC access point 

The following SDL-92 system specification defines operation of the MAC protocol at an IEEE 802.1 1 AP. 
Many aspects of AP operation are identical to the STA operation. These are defined in blocks and processes 
referenced from both the STA and AP system specifications. Blocks and processes used in both STA and AP 
are identifiable by the SDL comment /* for STA & AP */ below the block or process name. Blocks and pro- 
cesses specific to AP operation are identifiable by the SDL comment /* AP version */ below the block or 
process name. Definitions for the /* AP version */ and the /* STA & AP */ blocks and processes appear in 
this subclause. 

The remainder of this clause is the formal description, in SDL/GR, of an IEEE 802.1 1 AP. 
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use macsorts 
use macmib : 



System Access. Pomt 



jjvlsdulndicatej 



ToDsm ] 



DSM 



JVromDsmJ 



MaUnitdata.indicatton. 
MaUnitdataStatus. indication 

MAC.SAP 
MaUnitdata. request j 



MAC .Data. 
.Service 

r for STA & AP7 



RSDU 



TSDU 



1 



'Includes request 
.-i validation and 
' add/remove 
[MAC headers. 



(MlmeConfirmSignals). 1 
(MlmelndicationSignals) 

SM.MLME.SAP 



AP_1b(3) 



J(MlmeRequestSignals)j 



MAC_Manage_ 
ment_Service 
r for STA & AP*/ 



MsduConfirm 



i Includes encryption, 

.[fragmentation. TIM 

j i generation, and 
, | queuing for BC/MC. 
i , PSM, CFP & fromDS. 



^MsduRequestJ 



Distribution, 
.Service 
/'only at APV 



Msdu_ 1 
Indicate 

TODS 



FRDS 



1 



Msdu. "I 
Confirm 



| r Msdu. 1 
Request 



mpdu_ 
Generation_AP 
f" AP version V . 



AsChange. 
MmRequBst. 
PsChange. 
Ps Response 



Oslnquiry.l 
DsNotrfy 



TPOU 



MMDS 



Includes DCF. PCF, 
PS-Poll response. J 
Acknowledgement i 
Rts/Cts, and retry. 



JPduRequestJ 



PduConfirm.l 
PsPolled 



^DsResponseJ 



ProtocoL • 
_Control_AP 
I" AP version*/ 




TX 



BkDone. 
TxConf rm 



Backoff. 
Cancel, 
TxRequttst 



[(PlmeCon_ 1 
firmSignals) 



r for STA A AP */ 



Busy, 

Idle. 

Stor 



£(Ph yTxConfirmSkj nals )J 

yvwrsAPyy----- 

I (PhyTxRequestSignals) 



MCTL 



MmCancel, 

SsResponse. 

SwChnl 





Mmlndicate. 




Sslnquiry. 




SwOone 



MMTX 



[MmConfirm. | 
Pslnquiry 



'Includes MAC Ml£" 
--.J MIB access, and 
[ filtenng of Mime 
I request and confirm. 



| (MmgtConfirmSignals). 1 

S) J 



j^{MmgtlndtcationSignals)J 



MMGT 



JjM mgtRequestSignals)j 



MLME.AP 
/*AP version */ 



^Pslndtcatej 



Rxlndicate. 

NeedAck, 

RxaAck 



CS 



MLME.PLME.SAP 



* "jjP) rne Req'ue it Stg nals) j " 



RX 



[changeNavj 



i Includes start BSS. 
.-t beacon, dwell. CFP 
i & occupancy timing. 
| (re/dis)associate. 
[ (de)authenbcate, 
[probe response, and 
[ monitor of station 
! & power save state. 



PS 



[^ChangeNavJ 



Reception 

r for STA 4 AP * 



£(PhyRxSignals)J 

-PJiY_SAp_8X__ 
|VhyCcarst.requestj 



i Includes validate, decrypt. 
J address A duplicate filter, 
/i defragment, channel state 
/ ] (physical and virtual earner 
i sense), and IFS & slot timing. 



phy <5ap pv | Includes backoff. 

. -FJiY_SAP_8X J pes generate, and 



itimestamp insert. 
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use macsorts : 
use macmib : 



System Access _ Point 



AP_signals_2d(3) 



newtype OsStatus literals 

assoc. disassoc. reassoc. unknot 
endnewtype OsStatus : 



signal 

A sC ha nge( Frame. OsStatus). 
B ac koff (I nte ger . I nteger) . 
BkDone( Integer). 
Busy. 
Cancel. 

ChangeNav(Time.Duration.NavSrc), 

Dslnquiry(MacAddr.MacAddr), 

DsNotify (MacAddr. OsStatus), 

DsResponse(MacAddr.MacAddr.DsStatus), 

FromDsm(MacAddr.MacAddr.Octetstring), 

Idle. 

MaUnitdata.indication(MacAddr,MacAddr. 

Routing .Octetstring.RxStatus. 

CfPnortty.ServiceClass). 
MaUnitdata.request(MacAddr.MacAddr. 

Routing.Octetstnng.CfPriority.ServiceClass). 
MaU m tda ta Statu s. ind icatton (M acAd dr. 

MacAddr. Tx Status. CfPriorrty.ServtceClass), 
M I meAssociat8.confirm(M ImeStatus), 
MlmeAssociate. ind ication{M acAddr), 
M ImeAssociate. request (Mac Add r.Ku sec. Capability.) nteger). 
M I m eAuthenticate. co nfirm 

(MacAddr.AuthType.MlmeStatus), 
M ImeAuthenticate. indication (MacAddr.Au th Type), 
MlmeA uthenticate. request( MacAddr, AuthType. Kusec), 
MlmeOea uthenticate. co nfi rm ( MacAddr . MlmeS tatus). 
MlmeOea uthenticate. indication (MacAddr. ReasonCode), 
MlmeOea uthenticate. requ est( M acAddr. ReasonCode). 
M ImeD isassociate . confi rm(M ImeStatus), 
M ImeD isassociate. indication (M acAddr. Reason Code), 
MlmeDisassociate.request(M acAddr. ReasonCode). 
M ImeG et.confirm(M ib Statu s.MtbAtnb.M ib Value), 
MlmeGetrequest(MibAtrib), 
MlmeJoin.confirm(MlmeStatus). 
MlmeJoin.request(BssDscr. Integer, Usee. Rat estring), 
MlmePowermgt. co nfi rm(M ImeStatus) , 
M ImePowermgt. request(PwrSave. Boo lean, Boolean ), 
MlmeReassociate.confirrn(M ImeStatus), 
MlmeReassociate. indication (MacAddr), 
MlmeReas30Ciate.request( MacAddr, Kusec, Capability, I nteger) 
Ml meReset. confirm(M ImeStatus), 
MlmeReset. request 

MlmeScan. confi rrn(BssOscrSetM ImeStatus). 
MlmeScan. requestj B ss TypeSet MacAdd r.Octetstri ng, 

Scan Type. Usee. Intstring, Kusec, Kusec), 
MlmeSetconfirm(MibStatus,MibAtrib), 
MlmeSetrequest(MibAtrib.MibValue), 
M tmeSta rt confirm(MlmeStatus). 
MlmeStartrequest{0ctetsthr>g,Bs3Type,Kusec. 

I ntegof.CfParms. PhyParms, IbssParms.U sec, 

CapebtWy.Ratestnng.Ratestnng) ; 



signal 
MmCancel. 
MmConfirm(Frame.Tx Status). 
Mmlndicate(Frame.Time.Time.StateErr), 
MmRequest(Frame.lmed.Rate). 
MsduConftrm(Frame.CfPrionty.TxStatus). 
Msdul ndicatej Frame. CfPrionty), 
MsduRequest(Frame.CfPrtority), 
NeedAck( MacAddr. Time, Duration. Rate). 
PduConfirm(FragSdu.TxResult), 
PduRequest(FragSdu). 
PhyCca. ind ication(C casta tus), 
PhyCcarst. con firm. 
PhyCcarsl. request. 
Phy Data, confirm, 
PhyData.indication(Octet). 
PhyData.request(Octet). 
PhyRxEnd. indication (Phy RxStat), 
PhyRxStart. indication (Integer. Rate). 
PhyTxEnd.confirm. 
Phy TxEnd. request, 
Phy Tx Start . co nfirm . 
Phy Tx Start, requests nteger. Rate). 
PlmeCharacteristics.confirm(PhyChrstcs). 
PlmeCharacteristics. request 
PlmeGet.confirm(MibStatus, 

MibAtrib.Mib Value), 
PlmeGet.request(MibAtrib). 
PlmeReset confi rm(Boolean), 
Pi meReset request 
PlmeSet.confirm(MibStatus.MibAtrib), 
PlmeSet.request(MibAtrib.MibValue). 
PsmDone, 

PsPolled(MacAddr.Asocld). 
PsC ha nge( MacAdd r.PsMode), 
Pslnd!cate(MacAddr.PsMode). 
Psfnquiry( MacAddr). 
PsResponse(MacAddr.PsMode). 
ResetMAC. 
RxCfAck (MacAddr), 
Rxlndicate(Frame. Time, Time. Rate), 
Slot. 

Sslnquiry( MacAddr). 
S sR as ponse(M acAddr. 

Station State. StationState). 
SwChn 1(1 nteger. Boolean), 
SwOone. 

ToOsm(MacAddr.MacAddr.Octetstnng), 
TxConftrm, 

Tx Request ( Frame. Rate) ; 
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use mac sorts 
use macmib ; 



System Access.Pomt 



AP_signal!ists_3b{3) 



signallist K 
MlmeRequestSignalsa ^ 

Mime Associate, request 

M I meAuthenticate. request. 

MlmeOeauttient tea te. request. 

MlmeDisassoaate .request 

MlmeGet request 

Mime Join, request. 

MlmePowermgl.request 

MlmeReassociate. request 

MlmeReset. request, 

M ImeScan .request. 

MlmeSet request 

MlmeStart. request : 



signallist [\ 
M!meConfirmSignals= 

MlmeAssociate.confirm. 

M ImeAuthentrcate. confirm, 

MtmeOeauthenticate.confirm, 

MlmeDisassoaate. confirm. 

MlmeGeL confirm. 

MlmeJoin. confirm. 

MlmePowermgt.confirm. 

MlmeReassociate. confirm, 

MlmeReset confirm, 

M ImeScan. confirm, 

MlmeSet confirm, 

MlmeStart. confirm ; 



signallist j\ 
MlmelndicationSignals= *- 

MlmeAuthenticate. indication. 

MlmeDeauthenticate. indication. 

MlmeDisassoaate. indication. 

MlmeAssociate.mdication. 

MlmeReassociate. indication ; 



signallist [\ 
SmtRequeslSig rials = 

MlmeAssociate.request 

MlmeAuthenticate. request. 

MlmeOeautnenticate. request, 

MlmeDisassoaate .request. 

MlmeJoin. request. 

MlmeReassociate. requ est 

MlmeScan.request. 

MlmeStart. requ est ; 



signallist 

PhyTxRequestSignal 
PhyTxStart request, 
Phy Tx End. request, 
PhyData.request ; 



signallist N 
PtmeRequestSignals» L_ 

PlmeCharact eristics. request. 

PlmeGetrequosl. 

PlmeSet request 

PlmeReset.request 



signallist K 
SmtConfirmSignals= ^ 

MlmeAssociate.confirm. 

MlmeAuthenticate.confirm. 

MlmeDeauthenticate. confirm, 

MlmeDisassoaate. confirm. 

MlmeJoin. confirm. 

M ImeR eas sociate. confirm. 

M ImeScan. confirm, 

MlmeStart confirm; 



signallist k 
Ph y TxConfirmSig nals^ 
PhyTxStart.confirm, 
PhyTxEnd.confirm. 
PnyData.confirm ; 



signallist N 
PlmeConfirmSignals» ^ 

PlmeCharact ens tics, confirm, 

PlmeGet confirm, 

PlmeSet. confirm. 

PlmeReset. confirm; 



signallist K 
SmtlndicattonSignatss ^ 

M ImeAu th entica te . in dication. 

MlmeDeauthenticate. indication. 

MlmeDisassoaate. indication, 

MlmeAssociate. indication . 

MlmeReassociate. indication ; 



signallist 
PhyRxSignals= 

PhyRxStart. indication 

Phy Rx End . in d ication. 

PhyData.indication. 

Phy Cca. indication. 

PhyCcarstconfirm : 
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MAC _ SAP 



Block MAC_Data_Service 



MaUnitdataStatus.. 
indication 




Mac. Data. ia(i) 



/* This block provides |\ 
the MAC_SAP functions^ 
described in Clause 6. 
conveying MSOUs from 
and to the LLC entity. 
This block operates 
identically in STA 
and A P. but in STA 
the TSOU signal route 
connects directly to 
MPOU.Generation, and 
the RSOU signal route 
connects directly 
from Protocol_Control. 
whereas in AP both of 
these signal routes 
connect to Distnbution 
Service. V 



ToLLC 



FromLLC 



MSDU to LLC 

(1.D 



HvlaUnttdata. request j 



MSDU from LLC 
(1.1) 



1 



Msdulndicate] 



^MsduConfirmj 



RxMsdu 



TxMsdu 



MsduRequest 



RSDU 



TSDU 
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Process MSDU_to_LLC 



Msdu_to_LLC_1a(i) 



/* This process runs when | 
reception is successfully 
completed on an MSDU 
addressed to the local 
LLC entity. This process 
extracts the appropriate 
address and status info, 
removes the MAC header 
from the MSDU data field 
(the FCS and IV/ICV are 
removed much earlier in 
reception handling), and 
generates the indication 
to LLC. Reception status 
is always "successful" 
because a receive error 
causes the MSDU to be 
discarded before reaching 
MAC Data Service. */ 



del cf CfPnonty : 
del LLCdata Octetstnni 
del sa. da MacAddr : 
del sdu Frame : 
del srv Serv>ceClass 



To.LLC 



Msdulndicate, 
(sdu. cf) 



j From source of the RSOU channel. 
■ -j STA source is Protocol Control, 
i AP source is Distnbution Service. 



da:= addM(sdu) 



sa:= if frOs(sdu)=1 
then addr3(sdu) 
else addr2(sdu) fi 



srv:* 
if order8rt(sdu)»l 
then strictlyOrdered 
else reorderable ft 



Remove MAC header > I 

from beginning of P , LLCdata:* substr 

MSDU to obtain the ' «• (sdu. sMacHdrLng, 

LLC data octet string. | length(sdu) - 
sMacHdrtng) 



Reception status 
always successful 
because any error 
would prevent the 
MsduJndicate 
from reaching 
this process. 



MaUnttdata.. 
indicabon(sa, da. 
null.rt, LLCdata. 
nt_success.cf.srv) 
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Process MSDU_from_LLC 



From_LLC 



del cf CfPnority : K 
del LLCdata Octatstnn^f 
del rt Routing : 
dct sa. da MacAddr : 
del sdu Frame : 
del srv ServiceOass : 
dct stat TxStatus : 



\ MaUniL 

y>data._ 
y/ request 




(sa. da. rt. 
LLCdata. 
cf. srv) 


successful. 
retryLimrt. 
txLifetime. 
or noBss 








'validate 
parameters'. 
stat= 




if rt /= null_rt then 
nonNullSourceRouting 

else if (length(LLCdata) 
> sMsduMaxLng) or 
(length(LLCdata) < 0) 
then excassiveOataLength 

else successful fi fi 


<Z successful j> 



(true) 



MsduConfirm / 
(sdu.srv. / 
stat) \ 






srv:=s if 
orderSit 
(sdu) a 1 






da: 
toDs(s< 


= if 

Ju) = 1 





else 


stats 




unsupported. 




ServiceOass 





j: 



stats 
unavailable. 
ServiceClass 





(true) 


stat* 




noBss 






(reorderable) 



MaUnit. 

dataStatus. 

indication 



else 



stat= 
unsupported, 
Prionty 




i Reject Msdu 
- 1 if station 
1 not in BSS 
| or IBSS. 



(contention) 



(con tenfi on Free) 



MaUnrt. 

dataStatus.. 

indication 



(sa, da, 
stat 
cf, srv) 



CD 




(true) 



(sa. da. 
unavailable. 
Priority.cf, srv) 



Msdu_from_LLC . 1 b( 1 ) 



imported m Assoc. 

mDisable. mlbss. 

mPcAvail Boolean : 
imported 

dot! IPowerManagementMode PwrSave 
imported 
mBssId MacAddr ; 



then 

stricttyOrdered 
else reorderable fi 



then addr3(sdu) 
else addrl(sdu) 
fi 



(addr2(sdu). 
da. stat. 
cf. srv) 




r This process runs when [\ 
an MSDU to transmit is ^ 
presented by LLC. This 
process validates request 
parameters, and if valid 
attaches a basic MAC 
header and sends the MSDU 
to MPDU preparation (at 
STA) or to Dtstnbution 
Service (at AP). If request 
is invalid, or when status 
is available for the valid 
Tx attempt. LLC is informed 
by an MaUmtdataStatus._ 
Indication generated by 
this process. V 



Build frame with 24-octet 
MAC header and LLCdata: 

ftype:= data 

toDS :* 0 

addrt:= da 

addr2:= dot1 IMacAddress 

(sa parameter not used) 
addr3:= mBssId 
<other header fields> := 0 



do t1 IMacAddress, 

import(mBssld). 

LLCdata) 



"(strictly. 
Ordered) 



t If no PCF, 
- \ inform LLC. 
■ send Msdu in 
J in contention 
'period. 2nd 
! MaUnitdata. 
• Status reports 
! Tx result 



MsduRequest 
(sdu. cf) 



i Send Msdu to 
) — \ Mpdu preparation 
' (to distribution 
! service at AP) 
> with basic header. 

|| Other fields are 
> Tilled in prior 
! to transmission. 
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OSM 



RSDU 



TSDU 



Block Oistnoution.Service 



^ToDsmj 



DsDsm 



^FromDsmJ 



Msdu, 
Indicate 



-1 

ate I 



DsMd 



Msdu. ] 
Confirm 



MdOs 



Dist.Service_1a(l) 



Msdu_ 1 
Request 



OSM Interface 
(1.1) 

/* only at AP V 



OsBss 



MsduConfirm 



j^MsduRequestJ 



P This block interfaces \ 
between the AP function ^ 
and the Oistnbution 
System Medium, hence is 
only present at APs. 

In order to permit an LLC 
entity colocated with an 
AP to communicate via 
both the WM and the OSM. 
MAC. Data. Service at the 
AP interacts with this 
block. This causes frames 
originating at the station 
containing the AP to be 
treated equivalent^ to 
frames originating at any 
of the other stations 
associated with that AP. V 



Msdu. 1 
Indicate 



Oslnquiry. j 
DsNotrfy 



BssOs 



MlmeOs 



^DsResponsej 



FRDS 



TOOS 



MMDS 
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Process DSM .Interface 



0SM_data_la(2} 




MsduRequest\ 

osdu. y 

contention) y 




* True tf da is 
- -J addr of this 
' sta or active 
\ group addr. 



rsdu:= 
mkFrame 
(data. 




da. sa. 
DsmData), 
rsdu:=setFrOs 
(rsdu.1) 






/ Msduln, 
^ dicate(rsdu. 
\. contention) 






i True if da 
\ reached via 
' {one or more) 
I AP(wdsAddr). 



wdsAddr, 
da, DsmOata), 
tsdu:= 

msAddr4(sa). 
tsdu:=setf rOs 

(tsdu.1), 
tsdu:=setToDs 

(tadu,l) 



True rf da reached via (one t 
or more) AP(wdsAddr). '* 



' True if da is 
--laddr of asoc 
■ sta or any 
! group addr. 



addr3(rsdu). 
addr2(rsdu). 
substr(rsdu. 
sMacHdrLng, 
length(rsdu) - 
sMacHdrLng)), 
tsdu:=setFrOs 
(tsdu.1) 



t True if da is 
■I addr of this 
' sta or active 
\ group addr. 

( True if da ts 
\ any group addr 
> or addr of sta 
\ not asoc here. 

addr2(rsdu), 
substr(rsdu. 
sMacHdrLng, 
length (rsdu) - 
sMacHdrLng)) 



del da. sa. wdsAddr MacAddr ; |\ 
del ds m Data Octetstring : ^ 
del dss DsStatus : 
del rpn, tpn CfPnority : 
del rsdu. tsdu Frame : 
del trsl Tx Result : 




MsduRequest N 
(tsdu. 

contention) 



addr2(rsdu), 
addr3(rsdu), 
substr(rsdu. 
sMacHdrLng. 
length(rsdu) - 
sMacHdrLng)). 
tsdu:=setFrDs 
(tsdu.1) 



1o DsmT 



(false) (true) 



' True if da is 
-\ any group addr 
' or addr of sta 
\ not asoc here. 



<ToDsm 
(addrl 
^(rsdu). 




addr2(rsdu), 
substr(rsdu. 
sMacHdrLng, 
length(rsdu) - 
sMacHdrLng)) 



to Wds ?' 

[Itme) 



MsduRequest\ 
(tsdu. ^> 
contention) / 



J> — - 

^ DS.Idle j 



(false) 



tsdu:* 
mkFrame 
(data. 



wdsAddr. 

addr3(rsdu). 

substr(rsdu, 

sMacHdrLng, 

length(rsdu) - 

sMacHdrLng)). 

tsdu:= 

insAddr4 

(addr2(rsdu)), 
tsdu:=setFrOs 

(tsdu.1). 
tsdu:=setToOs 

(tsdu.1) 



Msdu Request 
(tsdu. 

contention) 



(false) 



DS.Idle 



wdsAddr, 

addM (rsdu), 

substr(rsdu, 

sMacHdrLng, 

length(rsdu) - 

sMacHdrLng)). 

tsdu:= 

insAddr4 

(addr2(rsdu)). 
tsdu:=setFrOs 

(tsdu.1). 
tsdu:=setToDs 

(tsdu.1) 



i True if da reached via (one 
"i or more) AP( wds Addr). 
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i Process OSMJnterface DSM_management_2a(2» 




i State continued 
i from previous page. 



i Pass confirm 
\ of LLC request 
• to Mac JOata_ 
I Service. 



DSJdle 



p~~~~7 / 'Notification 

<— -ic'a'ocreasoe. 

1 * ° 35 ' X ' or dtsasoc 
1 ^ ! from Mime. 



'update info 
about sta(da) 
with status dss' 



DSJdle 



Ds Inquiry 
(da. sa) 



"dss:= 
ds status of 
station (da]' 



sa:= ap 
addr where 
da is asoc' 



DsResponse 
(da, sa. dss) 



DSJdle 



i Inquiry about 
. \ existing asoc 
i status. Sent 
J by Mime when 
i validating 
! new asoc 
• or reasoc 
\ requests. 
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FRDS 



Block MPDU_Generation_AP 



1 



signal 

FragConfirm(FragSdu,Tx Result 
FragRequest(FragSdu) ; 



Includes encryption if 
dot1 1 PrivacyOptionlmplemented 
=true. This is a typical 
location, but implemented 
may use other locations 
between the MAC SAP 
and PHY_SAP_TXas 
long as they provide 
the specified behavior 
as observed at LLC. 
MLME and the WM. 



MsduConfirm 



Msdu 



ap,MPDU_gen_1a(1) 



Prepare.MPOU 
(1.1) 

/' for STA and AP V 



^MmConfirmJ 



/* This block converts 
outgoing Msdus and Mmpdi 
into Mpdus. fragmenting 
and encrypting as necessary 

The PM_Filter_AP process 
queues frames needing 
announcement in a TIM, 
and frames to be sent 
during the CF penod 
at an AP wrth an active 
point coordinator. This 
process also adds the 
TIM element to outgoing 
Beacon frames. 7 



PM.Filter.AP 
(1.1) 

/• AP version •/ 




PwrMgt 



AsChange, 
PsResponse, 
PsChange 



PduConfirm. 
PsPolled 



MMTX 



Mpdu 



JpduRequest 
TPOU 
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Process Prepare. MPOU 



prepare. ib( 2) 




| Procedure used for WEP encryption. 
- - If dotl 1 PnvacyOpttonlmplementeda 
i false, this procedure is not present. 



No.Bss 



imported mAssoc. mlbss. dotl IPnvacylnvoked Boolean ; \ 

imported dotl 1 Fragmentation Threshold Integer ; *A 

imported dot11WepOefaultKeys KeyVector ; 

imported dotl IWepDefaultKeytd Keylndex : 

imported dotl IWepKeyMappings KeyMapArray ; 

imported dotl IWepKeyMappingLength KeyMapArray Length • 

imported mCap Octetstring ; 



del bemc. keyOk. K 
useWep Boo lean falsffT| 

del f FragNum : 

del fsdu FragSdu : 

del mpduOvhd. p. 
pduSize. thld Integer : 

del pn CfPnonty : 

del rrsl Tx Result : 

del sdu. rsdu Frame : 



< 



import 
(mAssoc) 



and (not 

import(mAct_ 

ingAsAp)) 



Prepare 
_Bss ~ 



j All data frames 
- -, in Bss sent to 
i distrib. service 



< 



not import \ 
(mAssoc) ? 



1 



Msdu. 

Request 

(sdu.pri) 



No.Bss 



sdu:= 
setAddrl 
(sdu. import 
(mBssId)). 

sdu:= 
setToOs 
(sdu,1) 



sdu:» 
setAddr3(sdu. 
addrl(sdu)). 



Invoked) and 
dotl 1 Privacy. 
Option. 
Implemented 



useWep:o 
import( 
dotl 1 Privacy. 



Fragment and ' 
encrypt is |- 
on next page. i 




/* This process generatesK 
one or more Modus from* 
each outgoing Msdu or 
Mmpdu. If encryption is 
needed, the Mpdus are 
encrypted before being 
passed to be filtered for 
possible power save or 
CF queuing before tx */ 



< import \ 
(mlbss) / 



< import \ 
(mActing_ ^> 
AsAp) / 



Prepare, 
_lbss 



j All data frames 
in Ibss sent to 
i destination sta. 



A. 



1 



Msdu_ 

Request 

(sdu.pn) 



Prepare 
_AP " 



Msdu_ 
Request 

(sdu.pn) 



<not import \ 
(mlbss) / 

I 

^ No.Bss j 



3< 



MsduConfirrr 
(sdu.pn. 
noBss) 



No.Bss 



Msdu_ 

Request 

(sdu.pri) 



<not import \ 
(mActing. \ 
AsAp) ~ / 



No.Bss 



1 Mmpdus sent 
•J even when not 
i in Bss/tbss. 



^^ResetMAC 




Mm. / 
Request ^ 
(sdu.pri) \ 












^ No_ 


Bss 




bcmc:« 
isGroupf, 
addrl(sdu)) 












dotl 1 Privacy. 
Option. 
Implemented 
and if 

wepBrt(sdu)Bl 
then true 
else false fi 




useWep:" 




f fr ag_\ 








I ment J 


wepBiWrue in i 
request for 3rd 


] Confirm Msdu to < 
j MAC data service, \ 



Frag. 
Confirm 
(f sdu.pn. rrsl) 



Data frames 
rejected tf 
no Bss/lbss. 
Implementations 
may retain these 
frames until a 
Bss becomes 
(re)available. 



rsdu:" substr 

(fsdu! 
pdus(0). 0. 



sMacHdrLng), 
pri:a* fsdulcf 




base type 
[else 



(fsdu! 
pdus(0)) 



Msdu. 
Confirm 
(rsdu. pri. rrsl) 



1 (manage ment) 



MmConfirm 
(rsdu.pri.rrsl) 
to fsdulcnfTo 



frame of shared | 
key auth. seq. 



confirm Mmpdu to • 
MLME sub-block. ! 
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Process Prepare_MPDU 



fragment 2D(2) 



Initialize 
FragSdu 
structure 




fsdu!eoi:=0. fsdu!saf:=0. 
fsdu!src:=0. fsdu!lrc:=0. 
fsdu!psm:=false, 
fsdu!txrate:=0 




fsdu!grpa;a 

tsGrp( 
addrl(sdu)). 



fsdu!cf:=pri. 

f sd u ! cn fTo: =sender, 

fsdu Ires urn e:=false 



dot11 Fragmen, i 

tationThreshold \. 

must not be i 

>dot11Max_ < 

MpduLength. \ 







mpduOvhd:= 
sMacHdrtng ♦ • 
sCrcLng 


1 tv and tcv fields 
■- -J not counted in pre- 
i fragment overhead. 






pduSize: « 
import 


(dotl 1 Fragment, 
ation Threshold) 



(false) 



pduSize:= 
length(sdu) - 
sMacHdrtng 




pduSize:* 
pduSize - 
mpduOvhd 



t This is the typical 
■ i case, with the length 
i of all but the last 
! fragment equal to 
»dot11 Fragmentation _ 
| Threshold (plus 
i sWepAddtng if 
| useWepstrue). The 
i value selected for 
\ pduSize must be 
i>=256. even, and 
| <=aMpduMaxtength. 



fsdulfTot:* 
((length(sdu) - 
sMacHdrtng) / 



fsdulfTot» 





iffsdu'fTotsO 
then 1 

else fsduKTot fi 



fsdu!pdus(f): a 

null, 
keyOk:=false 



fsdu!pdus(f):3 
fsdulpdus(f) // 
substr{sdu.O, 



fsdu!pdus(f): 3 

setFrag( 
fsdu!pdus(f).f) 



fsdu!pdus(f):= 
setMoreFrag( 
fsdu!pdus(f).1) 



unavailable. 
KeyMapping) 



sMacHdrtng)// 
substr(sdu.p. 
pduSize) 




(false) 



(false) 



import(dot11WepKey_ 
Mappings), 

import(dot11WepKey_ 
MappingLength). 
import(dot11Wep_ 
DefaultKeys), 
import(dot1 1WepOefault_ 
Keytd). import(mCap)) 



pduSize:= if 

(p+pduSize) > length(sdu) 
then (length(sdu) - p ♦ 1 ) 
else pduSize fi 



' Final fragment may 
i be shorter than 
i initial/intermediate 
! fragments. 



i Encryption expands 
\ each pdu by 
i sWepAddLng. 
| hence Mpdus may 
i be longer than 
] dot1 1 MaxMpdutength 
, by sWepAddLng. 
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| Procedure Encrypt 



i : fpar in/out wpdu Frame, i \ 

] in/out keyOk Boolean. 

i in maps KeyMap Array, 

] in mapLength KeyMapArrayLength. 

i in kvec KeyVeclor. 

Jmkndx Keylndex. 

i in caps Octetstnng : 



lev field is 
encrypted, but 
this length 
is the pre- lev 
loop count. 



encrypting:* 
length(wpdu) - 
sMacHdrtng - 



(true) 




(=cPrivacy) 



kmap:= 
key Lookup 
(addrl (wpdu), 




(true) 



key:= 
kvec(kndx) 



Return error 
to LLC if 
key is null. 



Concatenate 
key with IV 
for encryption 
PRNG seed. 



Use RCA PRNG to 
generate an encrypt 
sting as long as the 
MPDUpaytoad 
plus the CV field. 




key» 
nullKw 



(false) 



key:» key // 
PmgKeyi 
newfV 



en crypt Str.» 
call RC4 
(Hey. 



encrypt, 1c(1) 



( 










tsWds:= 
toOs(pdu) and 
frOs(pdu) 



if isWds then 
sWdsAddLng 
else 0 fi 



del icv Crc : 

del encryptLng. k. n Integer . 
del encryptSlr. newfV Octetstnng 
del key PrngKey : 
del kmap KeyMap : 
imported procedure RC4 : 

fpar PrngKey. Integer: 

returns Octetstnng : 




, t Test if addr4 if isWds then 

- field is present. sWdsAddLng 
\ Only need at AP. else 0 fi 



k:= 0. 
n;= 

sWepHdrtng < 




J The IV generation algorithm 
\ is not specified, but use of 
> a new IV for each Mpdu is 
! recommended STRONGLY. 



ICV value 
calculated from 
plaintext 



Encrypt by xor ■ 
of payload with \- - 
encrypt string, r 



icv:= crc32 
(icv.wpdu(n)) 



wpdu(n):= 
wpdu(n) xor 
encryptStr(k) 



maps. 
mapLength) 




t Use default 
- \ key if no 
< mapping or 
! group dest. 



/* The algorithm for changing N 
dotHWepOefaultKeyld is not L 
specified.il all stations in the Bss 
have thesame values in the 
(relevant subsetof) 
dotl 1 WepOefaultKeys. 
a station's DefaurlKeyld algorithm 
does not affect interoperability. 7 




(false) 





(false) ^ena^J 








keyOk:n 
true 









(true) 




keyOk:» 
false 



■ If mapping 
\ keyOn=false. 
i do not encrypt. 


n: 


= o 






( 








raw ICV is Vs • 
complement of [--- 
crc32. MSb-first i 


icv:= 
mirror( 
not(icvj) 








(icv(n) 
xor 

encryptStn») 




wpdu:* 
wpdu// 








Encrypt ICV i j 
octets and J. > 
attach to end * 
of Mpdu. ! 


k:n k*1. 
n:» n*1 



encryptLng* 
sCrcLng) 




// newlV // 01 // 
substr(wpdu. sMac. 
HdrLng. encryptLng) 



Insert IV and keyld 
between MAC header--^ 
and data field. i 




Set WEP bit 
in Frame 
Control field. 



( 


rue) 


ls \sC ret ng/ 


wepdu:» 
setWepBtt 
(wepdu.1). 




keyOk:» 
true 



(false) 
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Process PM_Filter_AP 



ap^PM_Bss Jb(4) 
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Process PM_Filter AP 



ap_PM_Cfp_2t>(4) 




fsPend:« 
false 



Send null SOU if 
CFqueue empty. TxCtl}.- 
then responds with i 
CfAck or Null rather < 
than Oata or DataAck. | 



Pdu_ 


\ 


Request 




(nullSdu) / 







CD 
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Process PM_Filter_AP 



ap_PM_Asoc.3c(4) 



_L 



_i_ 



AsChange 

(rpdu. 

statAs) 



i AsChange sent by 
- - 1 AsocServics_AP to 
' indicate changes in 
! association status. 



PsChange 
(sta. statPs) 



asx:= 
Asocld of sta 
at addrl(rpdu)' 




• PsChange sent by 

- 1 Power. Save_Monitor to 

• indicate a change of power 
! save mode by a station. 




(asoc. 



asTb 
adA( 
addrl 


(asx)! 
Jdr:= 
(rpdu) 






'update 
asTbl(asx) with 
info in rpdu' 




(station .active) 



clear other 
values in 
asTbl(asx)' 



'drop frames 
for this sta 
from psQ' 



tmap(asx):=0 




T 



* Age-related processing 
- !, of association records 
■ is allowed, but no such 
i processing is required. 




asTbl(asx) 
!adPsm:= 
station, active 



tmap(asx);=0 



asx:= 
qSearch 
(psQ, sta) 




(<0) 



(power_sa 


ve) 




asTbl(asx) 




!adPsm:= 




power 


.save 




\ 





(>*0) 



txQ:*qiast 
(txQ.psQ( 
asx)). 



T 



Transfer any 
queued fsdus 
from psQ to txQ 
when power save 
station indicates 
change to active. 



psQ:= if asx=0 
then tail(psQ) 
else subQ(psQ. 0. asx-1)fi 
// rf asx=length(psCM) 

then emptyQ 

else subQ(psQ. asx+1. 

length(psQ)-asx-l) fi 
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Process TM.Filter AP 



ap_PM_PsPoil_4c{4) 



^ PM. 


.Bss 






PsPollod / 
( .rxAid) <v 






star* 
asocTbl(rxAid) • 
ladAddr 






psx:= 
qSearch 
(psQ. sta) 



j This page handles only PsPoll response 
• i selection. Other transitions from 
i PM.Bss state appear on other pages. 




set tlo and thi 
to range of Aids 
for this Tim' 




t Normally these cover 
- \ the range of Aid values 
> in use. but subsets 
! are permitted. 



fsdu!pdus( 
1):= 




fsdu'pdus(l)// 
mkTim{tmap, 
import{mDtimCount), 
importjdotl IDtimPenod), 
tlo. thi. 

if qSearch(psQ. 
bcstAddr)<0 
then false 
else true fi ) 



' No response if 
\ nothing queued 
i for sta. Causes 
• Tx_ Coord to 
i send Ack frame. 



fsdu:= 
psQ( psx), 




psQ:= if psx=0 
then tail(psQ) 
else subQ(psQ. 0. psx-1) fj 
//if psx=tength(psQ*1) 
then emptyO 
else subQ{psQ. psx+1. 
( length(psO)-psx-l)) fi 






psx:* 
qSearch 
(psQ. sta) 








(>»0) 



'set moreOata 

bit in each 
fsdu fragmenr 





(<0) 




tmap(psx):«0 



Pdu_ 

Request 

(fsdu) 



> 



> Tmap bits also are 
- \ cleared when the 
i last fsdu for an Aid 
! is removed from 
• the psQ due to 
[ TxLrfetime ex pin rig. 



fsPend:- 
true 
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RSDU 



TPDU 



Block Protocol_Control_AP 



signal 

Ack(Time.Rate). 
CfRsp(Time.Rate). 
Cts(Time.Rate), 
PsPoll(Frame.Time.Rate), 
TxCfAck(Time.Rate) ; 




PduConfirm. 
Ps Polled 



ap_CTL_ld{1) 



^PduRequestJ 



Tdat 



[BkDone. 1 
TxConfirm 



< Includes point 
— i coordinator 
' for use with 
[ optional PCF. 



MmCancel. 

SwChnl. 

Tbtt 



Rdat 



/* This block performs the K 
DCF functions, as well as ^ 
serving as Point Coordinator 
if the AP provides a PCF. 
Tx_Coord_AP includes the 
PC. RTS generation and 
(non-Ack) PS-Poll response. 
Rx_Coord_AP generates 
acknowledgements, routes 
management frames to MLME 
routes data frames to MAC 
Data Service, and signals 
Ack. Cts. and PS-Poll frames 
to Tx.Coord.AP. */ 




Tx_ Coordination 

_AP 

0.1) 

r AP version V 



TxO 



Pctl 



J^TxRequestJ 



PlmeGet. 

.confirm, 

PlmeSet_ 

.confirm, 

P1me_ 

Reset. 

.confirm 



WmeGel. 

.request 

PlmeSet. 

.request 

Plme Reset. 

.request 



Ack, 

CfRsp. 

Cts. 

PsPoll, 

TxCfAck 



Rett 



TxRx 



Trsp 




j^SsResponseJ 



Rx Coordination 
(1.1) 

/*forSTA& APV 




MCTL 



MLME_PLME_SAP 
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Process Rx_ Coordination 



aRxTxTurn_ 
aroundTime) 



first(import 
(mBratas)). 
stuff 

(aMpdu. 

Duration. 

Factor. 
sAckCtsLng 
+ aPlcpHdr_ 
Length) 
♦ aPream 
bleLength)) 



nt_coord.la(4) 



h CD 



dSifsOly:" 
dUsec 
(aSifsTime - 



dRsp:=dUsec( 
aSifsTime ♦ 
calcDur( 



1 Duration of 
- ■( PS-Poll and 
i Ack response. 




timer Tsifs : 



del ackFrom. ackTo MacAddr : K 
del dAck. dCts. dRsp. 'A 

dSifsDIy Duration : 
del endRx. strTs Time : 
del pdu. rspdu Frame ; 
del a Rate Rate : 
del sas. sau Station State : 
imported mNavEnd Time : 



No,Bss 



• The rest of 
--|No_Bss state 
i is on 3rd page. 



RxCJdle 



< import \ 
(mOisable) / 



Need Ack ~/ 
{ ackTo. endR*^ 
dAck.rxRate) X 



'RxCJdle state 
■ •[ continues on 
i next page. 



RxCfAck 
(ackFrom) 



dAck:= dAck - 
if dAck>0 then 
dRsp else 0 fi 



RxCfPoll 



Ack(O.O) 




i No parameter 
--.[values because 
t without CfPoll 
[during Cfpthe 
i transmitter 
j cannot send 
, after this ack. 



i Receipt of RxCfPoll 
.J while waiting to 
i send result of 
| NeedAck cancels 
■ regular Ack wait 
I and reports the 
" need for +cfAck 
] to TxCoord. which 
• will be in a 
[ Sifs wait when 
1 this signal 
| arrives. 
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Process Rx_ Coordination 



rx_coord^2b(4) 



1 RxCJdle state 
RxC_ Idle V — | is continued 

i from previous page. 





(ack) 


/ Ack 






{ {endRx. 




\^ rxRate) 










1 Class 1 frames handled 
-J on this page, class 2 and 
i 3 frames on next page. 



if import(mCfp) 
then contention_free 
else contention fi) 



RxCJdle 
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Process Rx. Co ordination 



r*_ coords 3D(4) 




' Beacon and probe _rsp 
\ sent to Mlme_Req_Rsp 
i white scaning. other 
! types acknowledged 
'(if umcast to this 
! station) out ignored. 



At station 
Rx with toDs=1 
i discarded by 
jFitter.MPOU. 
i frOs=1 never 
| sent by Sta, so 
i explicit fromOs 
| test not 
i needed here. 






(nuJijrame. disasoc. 






asoc.req. reasoc.req, 


(pspotl) 




asoc_rsp. reasoc^rsp) 





(data.ack. 
data_poll, 
data_poll_ack. 
cfack. cfpoll. 
cfpoll. ack) 
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Process Incoordination AP 



ap_txjnit_1e(8) 



^ ^ timer Tifs. Trsp 



ResetMAC 



PlmeReset. 
Request 



dSifsDelay:* 

dUsec 
(aSifsTime - 



aRxTxTurn_ 
aroundTtme) 



del ackctstime. bstat. chan.frametime, 

frametime2 Integer: 
del ccw Integers aCwMin : 
del curPm Bit : 

del doHop. psmChg, cont Boolean— false 

del dSifsDelay. endRx Time : 

del fsdu FragSdu ; 

del rtype Ftype : 

del rxAid Assodd ; 

del rxrate Rate ; 

del seqnum. ssrc, sire, n tnteger= 0; 
del tpdu. rpdu, rspdu Frame ; 
del txrate Rate ; 
del cont Boolean ; 



'mm rate: = 
rate to send 
mmpdus' 



ccw:= 
import 
(aCWmin), 



ssrc:= 


0. 


slrc:= 


0 



i Mm rate must be 
- - .j selected from 
imBrates. Other 
1 selection criteria 
, are not specified. 



K 



Imported dot1 IRtsThreshold. 
dot1 1 ShortRetryLimit, 
dot1 1 LongRetryLimit. 
dot1 1 Frag mentation Threshold, 
dot1 1 MaxTransmitMsduLifetime Integer : 



Backoff 

(CCW.-1) 



/* RANDOM NUMBER FUNCTION 
imported procedure Random ; 
fpar limit Integer ; returns Integer 



TxCJdle 



del exported FxlP Boolean— false ; K 
del cTfrg exported as ^ 

dot1 1 TransmittedFragmentCount 
cTfrm exported as 

dot1 1 Transmitted FrameCount, 
cTmcfrm exported as 

dot1 1 MulticastTransmittedFrameCount, 
cFail exported as dot 11 Failed Count. 
cRtry exported as dot1 IRetryCount. 
cMrtry exported as dot1 IMultipleRetryCount. 
cCts exported as dot1 IRtsSuccessCount, 
eNcts exported as dotl 1 RtsFailureCount, 
cNack exported as dotHAckFailureCount 

Counter32:= 0 : 
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Process Tx_Coordinalion_AP 



ap_txjdte_2d(8) 



TxCJdle 



'Ack. Cfend. Cts. Wake 
•*[ and MmCancel ignored 
I in TxC_ldle state. 



• These transitions are 
- ^- -[ only present at APs 
[ i with point coordinator. 



X 



Pdu_ 

Request 

(fsdu) 



' Entry when 
-j station wakes 
i up to transmit. 



X 



PsPoll 
(rpdu, 

endRx. rxrate' 



<not import( \ ' / txc_ \ 
mBkIP) / "t req i 




/ / import \ \ \ 



1 



TxCfAck 
(endRx. ) 



PsPolled 

(addr2(rpdu) 

Ald(rpdu)) 



X 



TxC.Cfp 



set(endRx 
+dS its Delay, 
Tifs) 



tpdu:= 
setSeq(tpdu, 
fsdulsqf) 



seqnum:= 
if seqnum=4095 
then 0 else 
seqnum+1 fi, 
fsdu!eol:= 
now + import 
(dot1 1MaxTransmit_ 
MsduLifetime) 



tpdu:= 
fdsulpdus 
(fsdu!fCur) 



"txrate:« 
selected tx 
data rate' 





(true) 



(false) 



Tifs 



■ See 9.6 for rules 
--j about selecting 
i transmit data rate. 



i AP responds 
\ to PsPoll after 
i Sifs with Ack 
| or data. Basis 
i for choice of 
1 response is 
i unspecified. 



rspdu:= 
mkCtl(ack.02, 
addr2(rpdu)) 



TxRequest V. 
(rspdu. rxrate) / 



tpdu:= 
setDurld 
(tpdu, 



tpdu:=setPwrMgt 

(tpdu,import( 
dot1 1 PowerMan_ 
ago m o ntM ode )) 




(aSifsTime + (calcDur(txrate.stuff(aMpdu_ 
Duration Fa dor. sAckCtsLng)) + aP!cp_ 
HeaderLength + aPreambte Length) + 
if (fsdu!fTot = (fsdutfCur+1))then 0 else 
((2*aSifsTime) + (calcOurftxrate.stuff 
(aMpduDurationFactor, sAckCtsLng)) + 
aPlcpHeaderLength + aPreambleLength) 
+ stuff(aMpduDuration Factor, ((length 
(fsdu!pdus(fsdu!fCur+1)) + sCrcLng)*8)) + 
aPlcpHeadertength+aPreambleLength) ))) 





import(mBssld). 
import{mBssld). 



addr1( 
fsdu!pdus( 
D) 







I 


^>Tifs 


• 



PduRe. 




quest(fsdu) J 


to self 










sCrcLng) > import(dot1 1 Rts Threshold)) and 
(not fsdulgrpa) and ((fsdu!fCur=0) or retry(tpdu) 
or fsdu! resume) and (not import(mCfp)) 



i See corresponding 
- -J page of station 
' version for comments 
| on usewith FH. 



stuff(aMpduDuration Factor, 
((length(tpdu)+sCrcLng)*8))+ 
aPlcpHeadertength+ 
a Preamble Length +(3*aSifsTime) + 
(2*caicDur(txrate, stuff(aMpdu_ 
DurationFactor.sAckCtsLng)) + 
aPlcpHeaderLength+aPreambleLength) ) 
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Process Tx_Coordination_AP 




BkDonef 
bstat) 




mFxlP:=true. 
cTfrg:= 
inc(cTfrg) 



export 
(mFxIP. 
cTfrg) 



TxRequest 
(rtsdu.txrate) 



Wait_Rts_ 
_Sent 





(false) 




Backoff( \ 

CCW.-1) ? 









TxC_ Backoff 











I 


TxConfirm / 


/ • / 








set(now+dUsec 
(aSifsTime + 
calcDur(txrate, 




stuff(aMpdu_ 

Duration Factor, 

sAckCtsLng))+ 

aPlcpHeader_ 

Length+aPre_ 

ambleLength+ 

aSlotTime). Trap) 






' Wait_Cts ) 



f end \ 



mFxJP:=false 



export 
(mFxIP) 



ccw:= 
aCWmin 




ap_tx_dcf_3d(8) 




Ack signal is 
generated 
when Ack, 
CfAck, or 
Data* Cf Ack 
received. 













TxConfirm / 


n 








set(now+dUsec 
(aSifsTime + 
calcDur(txrate, 




stuff(aMpdu_ 

DurationFactor. 

sAckCtsLng))+ 

aPlcpHeader_ 

Length+aPre_ 

ambleLength* 

aSlotTime), Trsp) 


\ 


y 


Wart 


Ack I 



_L 



Ack 

(endRx. 
txrate) 




Trsp 



cNack:= 
inc(cNack) 



export(cNack) 
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Process Tx_Coordination_AP 



ap_tx_dcf_3.ld(8) 



Wait Cts 



Cts 

{endRx. 
txrate) 


< 






reset 
(Trsp) 






ssrc:=0. 
fsdu!src:=0 






cCts:* 
inc(cCts) 






export(cCts) 






set(endRx 
+dSifsDelay, 
Tifs) 






tpd 
setD 
(tp 


u:= 

urid 

du, 





(aSifsTime + (calcOur(txrate, 
stuff (aMpduDuration Factor, 
sAckCtsLng)) + aPlcpHeader_ 
Length + aPreambleLength) + 
if (fsdulfTot = (fsdu!fCur+1 )) then 0 
else 

((2'aSifsTime) + (ca I cDur( txrate, 
stuff (aM pd uOuration Factor. 
sAckCtsLng)) +aPlcpHeader_ 
Length + aPreambleLength)* 
stuff(aMpduDuration Factor, 
((length(fsdu!pdus(fsdu!fCur+1)) + 
sCrcLng)*8)) + aPlcpHeader_ 
Length+aPreambleLength)fi)) 




(true) 



(false) 



cTfrm:= 
inc(cTfrm) 






X PduConfirm 
<Q (fsdu, 
\success) 







slrc:=0. 




fsdu!lrc:=0, 


ssrc:=0. 




fsdu!src:=0 








cTfrg:= 




If (fsdulgrpa) 


inc(cTfrg), 




then inc(cTmcfrm) 


cTmcfrm:= 




else cTmcfrm fi 




(false) 





set (now* 
dSifsDelay* 




aSlotTime. Trsp) 




/ 





TxC_Cfp 



Backoff 

(CCW.-1) 



TxC_ Backoff 
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Process Tx_Coordination AP 



ap_retry_4d(8) 





ccw:= if 
ccw = aCWmax 



Backoff 
(ccw, -1) 



(false) 



(true) 



PduConfirm 

(fsdu. 

retryLimit) 



. cFail:^ 
inc(cFail), 
cont:= false 



(false) 



export(cFail) 



then aCWmax 
else (2*ccw)+1 
ft 




fsdu!pdus(fsdu!fCur):= 

setRetry(fsdu!pdus{ 

fsdu!fCur).1) 



import(dot11Long_ 
RetryLimit) 





ssrc:= 




fsdu!src:= 


ssrc+1. 




fsdu!src+1 



(false) 



import(dot11 Short, 
RetryLimit) 



import(dot1 1 Long_ 
RetryLimit) 



(true) 




i This shows the case where the 
- \ same pdu is retried after the 
i backoff. It is also allowable to 
| return this fsdu to PM .Fitter with 
i statu s= partial, and to go to 
| TxC_Backoff state with cont=false. 
i This will allow a different pdu 
| (if available) to be sent as the 
i next transmission. 



TxC_ Backoff 
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Process Tx_ Coordination AP 



Pdu_ 

Request 

(fsdu) 



pack:= 
ftype(tpdu) 



tpdu:= 
fdsulpdus 
(fsdulfCur) 




tpdu:= 
setSeq(tpdu. 
fsdulsqf) 



tpdu:= 
setFtype 
(tpdu. 



*txrate;= 
selected tx 
data rate' 



Wait_Cfp_ 
Sifs 



1 See 9.6 for rules 
•| about selecting 
t transmit data rate. 



ap_pcf_6b(8) 



TxC.Cfp 



1 Transitions on this 
— page are only present 
i for point coordinator. 



i Attach CfPoll 
- 1 and/or generate 
i CfPoll without 
] data based on 
• polling list if 
| mCfPoll=true. 



<not import \ 
(mCfp) / 



tpdu:= 
mkFrame 
(cfend, 



Mmlnd_ 
icate(tpdu. 
. .noerr) 



seqnum:= 

seqnum+1. 
fsdu!eol:= 
now+ import( 
dotl1Max_ 
Trans mitMsdu_ 
Lifetime) 



Wait Cfp_ 
Sifs 



ftype(tpdu) 
or pack) 



' Change data to 
-| data+cfAck if 
t appropriate. 



Trsp 



set(now+ 
aSlotTime, 
Trsp) 



import{ 
mBssId), 
import( 
mBssId)) 




Wait_Cfp_ 
Sifs 



Trsp 



TxCfAck 
(.) 



TxRequest 

(tpdu, 

txrate) 



tpdu:= 
setFtype 
(tpdu.data_ack) 



cTfrg::: 
inc(cTfrg), 



cTmcfrm.™ 
if fsdulgrpa 
then inc(cTmcfrm) 
elsecTmcfrm fi 



export 
(cTfrg, 
cTmcfrm) 



Wait_Cfp_ 
TxDone 



TxConfirm 



set (now* 
dSifs Delay, 
Trsp) 



Wait CfAck 
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Process Tx_Coordtnation_AP 



ap_cf_retry_7b(8) 



i Send frame 
"i at Sifs 




set(endRx 
♦dSifsDelay, 
Tits) 



Wait.Sifs 



Tifs 



TxRequest 
(tpdu.trate) 



Wait_Tx_ 
Done 



TxConfirm 



TxCjdle 



Ack 

(endRx. ) 



(true) 



PduConfirm 

(fsdu, 

success) 



cTfrm:= 
inc(cTfrm) 



V wart J 



reset(Trsp) 



set(endRx+ 
dSifsOelay, 
Trsp) 



Txc_a P 



Wait^CfAck 



Trsp 



<import( \ 
mRxA) / 




fsdu!fCur+1 



cNack:= 
inc(cNack) 





(false) 




fsdu!fCur= 
fsdu!fCur+1 



export 
(cNack) 



tpdu:= 
setRetry 
(tpdu.1), 



fsdulpdus 
(fsdu!fCur):= 

setRetry 
(fsdulpdus 
(fsdu!fCur),1) 



(true) 



PduConfirm 
(fsdu, 
retry Limit) 




import(dot11Long_ 
RetryLimit)) 



PduConfirm 

(fsdu, 

partial) 



cFaii:= 
inc(cFail) 



cRtry:= 
tnc(cRtry) 



export(cFail) 



i This returns the fsdu 
-\ to the queue. At the 
i next cf-poll, either 
| the same fsdu or a 
i different fsdu may 
J be selected for 
\ transmission. 



export(cRtry) 
1 



set(now+ 
aSlotTime, 
Trsp) 



TxC_Cfp 
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Block Transmission 



* This block does octet- N 
level transfers of MPDUs^ 
from the MAC to the PHY 
transmitter, generating 
FCS fields and inserting 
time stamp values where 
necessary. Process Data_ 
Pump begins transmitting 
when TxRequest arrives. 
The sender of TxRequest 
is assumed to have done 
the appropriate actions 
prior to transimtting onto 
the WM. If these actions 
include performing random 
backoff or invoking the 
"backoff procedure" (see 
9.2.5.2), a Backoff signal 
is sent to process Backoff. 
At the completion of each 
backoff, a BkDone signal 
is returned to the sender 
of the Backoff signal at 
the correct time to send 
a TxRequest. The medium 
state updates (busy, idle, 
slot) from Channel_State 
are forwarded to Backoff _ 
Procedure via Data_Pump 
to prevent decrementing 
the backoff count while 
transmitting Cts or Ack 
frames. This block is used 
in both station and AP. 7 



^TxConfirmj 



Txrq 



BkDone 



transmit. 1a(1) 



Bkof 



[Backoff. 
Cancel 



Backoff Procedure 
(1.1) 




CS 



PhyTx Start, confirm. 
PhyTxEnd .confirm. 
PhyData. confirm 



ToPHY 



PhyTx Start request. 
PhyTxEnd.request, 
PhyOata. request 



PHY_SAP_TX 
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Process Data _ Pump 



transmit. 1a(1) 



1 Delay from 
-| Phy_Sap(tx) 
i to antenna. 



(Txjdle) 



> 



del fes Crc ; 
del dTx 

Duration ; 
del k. txLength 

Integer ; 
dci pdu Frame ; 
del rate Octet : 
del source Pld ; 



imported K 
procedure Tsf 
fpar Integer. 
Boolean: 
returns Integer ; 



ResetMAC 



1 No TxConfirm 
• -| if Tx halted 
i by ResetMAC. 












dTx:= dUsec 
(aTxRfDelay + 
aTxPlcpDelay) 




PhyTxEnd. \ |D° not wait 
request >— jferTxEnd.. 

/ ' i confirm. 


\ 








* 





fcs:= crc32 
(fcs.pdu(k)) 






k:= 


k+1 



Txjdle 



> Pass Busy. Idle and Slot signals 
--, to Backoff_Procedure while Tx is 
i idle, but not during transmissions. 



TxRequest 
(pdu. rate) 



source:= 
sender 



k:= 0, 
fcs:= initCrc 



txLength:= 
Length(pdu) 



Busy 



PhyTxStart. 
request 



Wait.TxStart 



Busy / 


Idle 


Slot <^ 










</^Busy 


/ Idle 


^Slot 








1 





i Plcp length is 
--] Mpdu length 
i + Fes length 



> Indicate medium 
- \ busy to freeze 
i backoff count 
! during transmit. 




(txLength+ 

sCrcLng, 

rate) 





/* This process sends an K 
Mpdu to the Phy while ^ 
generating & appending 
the Fes. On beacons and 
probe responses inserts 
(TSF + Phy TxDelay) in 
the timestamp field at 
confirm of octet 23. 

To transmit after Sifs, 
send TxRequest at end 
of the M1 interval (see 
9.2.10). For Pifs. Difs, 
or any backoff slot, 
TxRequest is sent at the 
end of the appropriate 
M2 interval. V 



i Send the 1's 
\ complement 
i of calculated 
| FCS value, 
! MSb to LSb. 



(true) 



PhyData., \. 
request } 
(fcs(k)) / 






k:= 


k+1 







PhyTxEnd.. 
request 



WaiLTxEnd 



Send_CRC 



PhyTxEnd.. 
confirm 




At confirm 
of octet 23. 
insert TSF + 
Phy Tx delay 
into [24:31] 
of beacon or 
probe rsp. 



pdu:=setTs 
(pdu.call Tsf 
(0,false)+dTx) 




TxConfirm goes 1 
to process that j- 
sent TxRequest. i 



TxConfirm 
to source 



Txjdle 
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Process Backoff. Procedure 



backofMb(2) 



No_Backoff 



cw is contention 
window, cnt is 
slot count from 
previous BkDone. 
tf cnt<0. a new 
random count 
is generated. 



\ Backoff 
~ / (cw. cnt) 



/* This process performs the K 
Backoff Procedure (see 9.2.5.2).^ 
returning Oone(-1) when Tx may 
begin, or Oone(n>=0) if cancelled. 
Backoff(cw.-I) starts new random 
backoff. Backoff(x.n>=0) resumes 
cancelled backoff. Backoff(O.O) 
sends Done(-I) when WM idle. V 



source: = 
sender, 
mBklP:=tnje 



' Save Ptd from 
-\ request to use 
i as addr of Done. 



export 
(mBkIP) 





(<0) 


Choose random < 
backoff count \ — 
if cnt = -1 : i 


slotCnt= call 
Random(cw) 





T 




slotCnt:= cnt 



At start assume that the WM 
is busy until receiving a signal ]- 
which indicates the WM is idle, i 



1 Resume with count 
- -j from cancelled 
i backoff if cnt>=0. 



/* Input Signal Summary K 
BUSY is sent by ChanneLState ^ 
when the WM changes from idle 
to busy due to CCA and/or NAV. 
and by Data_Pump at TxStart. 
CANCEL is sent by TxCoordination 
to terminate a backoff and return 
the residual backoff count value. 
IDLE is sent by Channel, State at the 
end of the M2 interval (see 9.2.10) 
that busy WM has been idle (CCA & 
NAV) for DIFS (EIFS after Rx error). 
SLOT is sent by Channel_State at the 
end of each M2 interval (see 9.2.10) 
while the WM is idle. 
Busy, Idle and Slot are forwarded 
from ChanneLState via Data_Pump 
when transmit is not in progress. V 



Channel_Busy 




Transitions to 
Channeljdle 
also align the 
Backoff signal 
arrival time to 
slot boundary 
(M2) timing. 













I I I 




Idle <^ 


Slot , 


Busy 


<^ ^^Cancel 






£ , . , ! 







^ Channeljdle ^ 




Slot only sent 
when WM idle. 
This is for the 
case where WM 
idle at arrival of 
Backoff signal. 




snd_ 
BkDn . 



del slotCnt, 
cw, cnt 

Integer ; 
del source Pld; 
del exported 
mBkIP 
Boolean: = 
false ; 



No_ Backoff 



/• RANDOM NUMBER FUNCTION VN 
imported procedure Random ; ^ 
fpar limit Integer ; returns Integer 
/' This function returns an integer 
from a uniform distribution over 
the range (0 <= value <= limit). 
Implemented need to be aware 
that proper operation of the MAC 
protocol requires statistically 
independent (pseudo-)random 
sequences to be generated by 
each station in a service area. 7 
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Process Backoff_Procedure 



backoff. 1.1 a(2) 



Channeljdle 



' Finish at M2 of proper slot, 
-[ even if slotCnt =0 
i at entry to state. 



Cancel has priority over other 
transitions. Done(0) returned if 
Cancel arrives at instant 
slotCnt:=0. 
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SM_MLME_SAP 



Block MAC_Management_Service 



MlmeGet.confirm. 
MlmeSet confirm. 
MlmeReset. confirm 



GetSet 



This process is 
a summary of 
MIS access. 
MIB attribute 
definitions 
(in ASN.1) are 
in section C.4. 



MlmeGet. request, 
MlmeSet, request. 
MlmeReset.request 



MIB (1,1) 



MlmeReset.request 
sends a ResetMAC 
signal to every 
process in every 
biock. To reduce 
diagram clutter. 
ResetMAC signal 
routing is not shown 
outside this block. 



Mres 



Mac_Mgmt_1a(1) 



ReqConfirm 



MlmeAssociate.confirm. 
MlmeAuthenticate. confirm, 
MlmeDeauthenticate.confirm. 
MlmeOis associate. con firm, 
M ImeJoin. confirm. 
MlmePowermgt.confirm, 
MlmeReassociate.confirm, 
MlmeScan.conftrm, 
MlmeStart. confirm 



MlmeAssociate.request 
M Im eAu th enticate. re que st , 
MlmeD ©authenticate, request, 
MlmeOisassociate. request. 
M ImeJoin. request, 
MlmePowermgt.request. 
MlmeReassociate.request 
MlmeScan. request. 
MlmeStart. request 



Indications 



MlmeAssociate.^ 
indication, 
MlmeAuthenticate. _ 
indication. 

MlmeDeauthenticate. _ 
indication. 

MlmeOisassociate.. 
indication. 
MtmeReassociate._ 
indication 



This process handles 
requests sequentially. 
Start, join, powermgt. 
scan, re/d is/associate 
and deauthenticate 
must be sequential, 
tt is possible to have 
multiple authentication 
sequences in progress 
concurrently. To allow 
this, AuthReq_Service 
in the MLME block 
would have to cache 
challenge text and 
match responses to 
cached request info. 



[^ResetMAcJ 



Mlme_Requests 
(1.1) 



Mlmejndications 
(1.1) 



7fy 



r In this block are [\ 
the MAC MIB and ^ 
MLME_SAP service 
primitives described 
in Clause 10. The 
MLME services are 
performed in the 
MLME block. This 
block is used both 
in station and AP. */ 



ToMgt 



MlmeAssociate.confirm, 
MlmeAuthenticate.confirm, 
M I meOeau thenti cate .confirm , 
MlmeOisassociate .confirm. 
M ImeJoin. confirm, 
MlmePowermgt.confirm, 
MlmeReassociate.confirm, 
MlmeScan.conftrm, 
MlmeStart. confirm 



MlmeAssociate.request 
MlmeAuthenticate. request. 
MlmeDeauthenticate. request. 
MlmeOisassociate. request, 
M ImeJoin. request. 
MlmePowermgt.request. 
M Im e R eas social e. request. 
MlmeScan. request, 
MlmeStart. request 



MlmeAssociate._ 
indication. 
MlmeAuthenticate., 
indication, 

MlmeDeauthenticate.. 

indication, 

MlmeOisassociate., 

indication. 

MlmeReassociate._ 

indication 



FromMgt 



MMGT 
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Process Mlmejndicattons 



Mlmejndication_1a(1) 



del alg AuthType : 
del rsn ReasonCodi 
del sta MacAddr ; 



Pass_ 
Through, 
Idle 



MlmeAsso_ 

ciate.ind_ 

ication(sta) 



MlmeAsso_ 

ciate.ind_ 

ication(sta) 



1 This state machine passes indications through, unmodified, from 
--[ MLME to the MLME SAP. MlmeAssociate. indication and 
i MlmeReassociate. indication are only generated by MLME at APs. 



MlmeAuthen 

ticate.ind_ 

icationfsta.algf 



MlmeDeauth_ / 

enticate.ind_^ 

ication(sta.rsn)\ 



MlmeAuthen. 

ticate.tnd_ 

tcation(sta.alA) 



X 



MlmeOisas 
sociate.ind^ 
ication(sta.rsn^ 



<MlmeDeauth 
enttcate.tnd_ 
ication(sta) 



MlmeReas_ 
sociate.ind_ 
ication(sta) 



<MlmeDisas_ 
sociate.ind_ 
tcation(sta) 



\1/ 



<MlmeReas_ 
sociate.ind_ 
ication(sta) 
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Process MIB 



Mib_access_1a(2) 



del x MibAtrib ; f\ 
dclv MibValue: 1 "^ 
del adr MacAddr ; 
del dflt Boolean : 



* This process performs N 
MlmeGet, MlmeSet. anlT 
MlmeReset functions. 
MIB access and update 
is described informally 
to avoid creating a full 
definition of the MIB 
in SOL (and anticipating 
the integration of the 
ASN.1 MIB definition 
using Z. 105). 7 



\^ MImeRe_ 

y set. request 
/ (adr.dftt) 



ResetMAC 




'reset read-write 
attributes to 
default values* 



dot11MacAddres: 
set to adr if 
adr is non-null* 



'export values 
of attributes 
declared here' 



Mlme_ 

Reset.con_ 

firm(success 



('write_only') 




('invalid') 



< MlmeSet, 
confirm 
(invalid, x) 



i ResetMAC is sent to all processes 
- ,, in all blocks. However, to reduce 
> clutter and enhance readability. 
, ResetMAC is omitted from signallists 
* and signal routes needed solely for 
i the ResetMAC signal are not shown. 



i Reset read-write attributes in the MAC 
-\ MIB. The write-only attributes in the 
i privacy group may also be reset. 
| If there is a (non-Mime) means to alter 
j any of the read-only attribute values, 
i they must be restored to default values. 



i A locally-administered MAC address 

■J may be used in lieu of the unique, 

> globally-administered MAC address 

J assigned to the station. However, the 

• value of dot1 IMacAddress may not change 

, during MAC operation. 




('read_only') 



■export(x)* 



MlmeSet _ 

confirm 

(success,x) 
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Process MIB 



Mib_import_export_2b(2) 



r Import of {Read-Only) MIB counter 

values exported from other processes 
imported 

dotl 1AckFailureCount, 

dot11FailedCount, 

dot1 IFcsErrorCount 

dot1 IFrameDuplicateCount. 

dotl IMulticastReceivedFrameCount, 

dot1 1 MulticastTransmittedFrameCount, 

dotl 1 Multiple RetryCount 

dot1 IReceivedFragmentCount, 

doll 1 RetryCount, 

dotl IRtsFailureCount. 

dotl 1 RtsSuccessCount. 

dotl 1 TransmittedFragmentCount. 

dotl IWepExcludedCount, 

dotl IWeplcvErrorCount, 

dotl IWepUndecryptableCount Counter 32 



/* The following Read-Only attributes in the K 
MAC MIB are defined as synonyms (named ^ 
constants) rather than remote variables 
because they describe properties of the 
station which are static, at least during 
any single instance of MAC operation: 

dotl 1 AuthenticationAlgorithms AuthTypeSet, 

dotUCfPollable Boolean. 

dot11MacAddress MacAddr, 

dotHManufacturerlD Octetstring, 

dotHPrivacyOptionlmplemented Boolean. 

dot11 Product! D Octetstring, 

aStationID MacAddr, 

dot 11WepKey Mapping Length Integer; 

In addition, all Read-Only attributes in the 
PHY MIB which are accessed by the MAC 
are defined as synonyms. 

7 



/* Declarations of MIB attributes exported from F\ 
this process */ L 

/* Read-Write attributes V 
del exported 
dotl 1 AuthenticationAlgorithms AuthTypeSet:= 

incl(open_system. shared_key). 
dotl 1 Exclude Unencrypted Boolean:* false, 
dotl IFragmentationThreshold Integers 2346, 
dotl IGroupAddresses MacAddrSet:= empty, 
dotl ILongRetryLimit lnteger:= 4, 
dotl IMaxReceiveLifetime Kusec:* 512, 
dotHMaxTransmitMsduLifetime Kusec:= 512, 
dot11MediumOccupancy Limit Kusec* 100, 
dotl 1 Privacy Invoked Boolean: = false. 
mReceiveDTIMs Boolean:= true, 
dotUCfpPeriod Integer* 1, 
dotUCfpMaxDuration Kusec:= 200, 
dotl lAuthenticationResponseTimeout Kusec:= 512. 
dot11RtsThreshold Integer* 3000, 
dotUShortRetry Limit Integer* 7, 
dotl IWepDefauitKeyld Keylndex:= 0. 
dotl iCurrentChannelNumber Integer:* 0. 
dot11CurrentSet Integers 0, 
dotl ICurrentPattem Integer* 0, 
dotl ICurrentlndex Integer* 0 ; 

/* Write-Only attributes V 
del exported 
dot11WepDefaultKeys KeyVector* nullKey, 
dotl IWepKey Mappings 
KeyMapArray:* (. nullAddr, false. nullKey .) : 



r NOTE: K 
The values listed for MAC MIB attributes are the^ 
specified default values for those attributes. 
The values listed for PHY MIB attributes are either 
the default values for the FH PHY. or arbitrary 
values within the specified range. The specific 
values for PHY attributes in this SDL description 
of the MAC do not have normative significance. 

7 
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Process Mlme_Requests 



Mlme_request_1b(3) 



del exported mActingAsAp |\ 
Boolean:= false : ^ 

imported mAssoc. 
mlbss Boolean ; 



newtype MRqState 
literals idle. bss. ibss. 
endnewtype MRqState : 

del rqState 
MRqState:= idle ; 




I* This process tracks K 
the synchronization state - ^ 
of the station as Idle 
(not pari of any Bss), 
Ibss (started or joined 
an independent Bss), Bss 
(joined an infrastructure 
Bss). or Ap (started an 
infrastructure Bss). 
Mime operation requests 
invalid in the current 
state are rejected here, 
while valid requests are 
passed to the Mime block 
for processing. This 
simplifies process flow 
and signal saving in the 
Mime block, because only 
meaningful Mime requests 
arrive for handling. 7 



del alg AuthType: K 

del bRate. oRate, ss Octetstring 1 ^ 

del bss BssOscr : 

del bssSet BssOscrSet ; 

del btype BssType : 

del cap Capability ; 

del dpm CfParms ; 

del enlist Intstring : 

del dtp. li Integer ; 

del dly Usee : 

del ibpm IbssParms : 

del phpm PhyParms ; 

del ps PwrSave ; 

del rs ReasonCode : 

del scan ScanType : 

del sta, bid MacAddr ; 

del sts MlmeStatus : 

del Sen. tmax, tmin, tmot Kusec : 

del typeSet BssTypeSet ; 

del wake, rdtm Boolean ; 



export 
(mAding_ 
AsAP) 




i Reject Authenticate, 
'■allow Start if idle 



Reject Start if 
not idle, allow 
Auth if neither 
IDLE nor AP. 



(ss. btype. tBcn. 
dtp. cfpm. phpm. 
ibpm, dly, cap, 
bRate. oRate) 





(independent] 


i < 

(true) 


Mlme_ \ 
Start,. y— 
request / 


\ 





\ MlmeAuth. 

^enticate.re^ - 
/ quest(sta. , ) 


' Reject as invalid 
---j due to not being 
i in a BSS. 






/ MlmeAuth_ 
^ enticate._ 
confirm 


(sta. 
invalid) 



Wait.Mlme 




ResetMAC 



rqState:= idle. 

m Acting. 
AsAp:= false 





^ Wait.Mlme ^ 



1 Reset and 

--jDeauthenticate 

i always allowed, 
t. _ . 



ZL 



MlmeOeau. 
thenticate.. 
request ( 



<MlmeStart._ 
confirm 
(alreadyBss) 



sta.rs) 



MlmeDeauth. 
enticate._re_ 
quest(sta.rs[ 



Wait.Mlme 



( ( Deau thenticate 
!. -| expunges local 
i authentication 
| record even if 
i there is no BSS 
j for sending the 
■ notification. 
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Process Mtme_ Requests 



Mlme_request_2c(3) 




' Reassociate request 
-] rejected as invalid 
t if not associated. 



/ MlmeReas. 
{ sociate.con_ 
\. firm (in valid) 




MlmeRe_ \ 
associate.^ 
request / 


/ J 










i 


Wait. 


Mime 



(sta. tmot. 
cap.N) 



MlmeScan.. 
request 

( ) 



MlmeScan., 
confirm 
( , invalid) 



AP 



1 Reject Scan, Join 
- •[ and Powermgt; allow 
i Disassociate at AP. 



(BSS) 



1 Reject Associate and 
Reassociate at AP and 
i at station not joined Bss. 



MlmeJoin.. 

request 

(-..) 



MlmePower, 
mgt. request 
(..) 



MlmeJoin., 

confirm 

(invalid) 



_L 



\^ MlmeDisas_ 

ysociate.re. 
/ quest(sta.rs) 



MlmePower. 
Mgt.confirm 
(not_supt) 



MlmeDisas_ 

sociate.re_ 

quest(sta.rs) 



Wait_Mlme 



1 If not AP. allow Join. Scan 
• -] and Powermgt, also allow 
t Disassociate if associated. 











\ Mlme_ 

y Associate.. 
y request(, , .) 


\. MlmeRe^ 

y associate. _ 
y request(, , .) 








y MlmeAssoc_ 
^ iate.confirm 
N. (invalid) 


y MlmeReas_ 
^ sociate.con_ 
firm(invalid) 









, ' Only AP may send 
s\\ disassociate to a 
1 i group address. 



N. MlmePower_ 






^> mgt.request[ 




ps,wake.rdtm) 




MlmePower. 
mgt.request( ^> 
ps.wake.rdtm)/ 
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Process Mlme_Requests 



Mlme_response_3a(3) 



Wait.Mlme 



MlmeAuthen_^^ 
ticate.confirm^ 
(sta.alg.sts) X 



1 Wait for MAC 
- -j management to 
i process request. 



Save new (request) ' 
signals while awaiting [-- 
response from MLME. i 



MlmeDeauth_ / 
enticate.con_^ 
firm(sta.sts) \^ 



MlmeAuthen 
ttcatexonftrrr 
(sta.alg.sts) 



Mime As _ 
sociate._ 
confirm(sts) 



<MlmeDeauth 
enticate.con, 
firm(sta.sts) 



_L 



MlmeReas. 

sociate._ 

confirm(sts) 



<MlmeAs_ 
sociate._ 
confirm( sts) 



I 



MlmeDis_ 

associate., 

confirm(sts) 



MlmeReas_ 
sociate._ 
confirm (sts) 




MlmeScan._ 

confirm 

(bssSet.sts) 



<MlmeDis_ 
associate.. 
confirm(sts) 



X 



<MlmeScan._ 
confirm 
(bssSet.sts) 



Scan leaves station 
in Idle state because 
synchronization with 
a previous Bss is lost. 
Implementations may 
save and restore TSF 
and association info 
to automatically re- 
join a previous Bss. 



rq State := idle 



IDLE 



(bss) 



(success) I 



rq State := idle 



BSS 



K 



(ap) 



IDLE 




(false) 




(true) 



rqState:» ap, 

mActing_ 
AsAP:= true 



(true) 









rqState:= bss 


\ 


/ 



rqState:= ibss 



export 
{mActing 
AsAP)" 



^ BSS j 



IBSS 



AP 
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MMGT 



Block MLME_AP 



Signal 
Sta State 
(MacAddr.StationState) 



MtmeDeauthenticate. confirm. 
MlmeDisassociate. confirm. 
MlmeStart.confirm. 
M!meAssociate.indication. 
MlmeAuthenticate. indication, 
MtmeDeauthenticate. indication. 
MlmeDisassociate. indication. 
MlmeReassociate. indication 



ap_MLME_1a(1) 



/* In this block are the handlers 
for Mime operation requests, 
the res ponders for incoming 
management frames, and the 
time synchronization function 
for the AP, as well as 
contention free period timing 
if this AP includes a PCF. 
This block also contains the 
process which maintains 
record of power save mode 
and station state for access 
by other processes. V 



MtmeDeauthenticate. request, 
MlmeDisassociate. request. 
MlmeStart. request 



MMTX 



MMDS 



MCTL 




i This process assumes 
\ that the Mime request 
i signals have been 
| validated by MAC 
i Management service. 
| and are restricted 
> to those appropriate 
!for use at AP. 
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Process Power_Save_ Monitor 



ps_monitor_1a(2) 



/* This process [\ 
records power ^ 
save state as 
indicated in the 
headers of all 
valid rx frames; 
and auth/asoc 
state from alt 
management 
exchanges by 
this station. V 



/* Each of these sets holds MAC addresses of |\ 
stations with a particular operational state. ^ 
Stations are added to and removed from sets 
due to MLME requests, received management 
frames, and bits in received MAC headers. 
Sets are not aged, as there is no requirement 
for periodic activity, but aging to expunge 
addresses of inactive stations is permitted. 

V del 

awake. /* detected in sta_ active mode */ 
asleep. /* detected in power_savB mode */ 
authOs, /* authenticated by open system 7 
authKey. /* authenticated by any other alg. V 
asoc r associated (0|1 member. non-AP) 7 
MacAddrSet ; 



del psm 

PsMode 
del psquery 

Boolean ; 
del sst. asst 

StationState : 
del sta 

MacAddr : 



Clear specific 
authentication 
info at startup 
but not reset. 



authOs:=empty. 
authKey:=empty 



1 Ps Indicate 
•[ signals from 
i Rx block. 



Monitorjdle 



1 Power Save Mode and 
--■| Station State monitoring 
i here, query on next page. 



Ps Indicate 
(sta. psm) 



StaState signals 1 
from Auth, Asoc j 
Mime services, i 



StaState 
(sta. sst) 



(sta_active) 




ResetMAC 



(power, save) 




J 



asoc:= 


empty 






awake: 
asleep: 


= empty. 
= empty 




✓ 



i Clear info on 
~\ power save and 
> associated 
1 stations at 
) startup and 
| at reset. 



Monitor Jdle 



awake:= 
Oel(sta, 
awake) 



asleep:* 
lncl(sta, 
asleep) 



<Ps Change 
(sta. 
sta_adive) 




■ Send PsChange 
\ when sleeping 

■ station reports 
! active mode. 



(auth.open) 



authOS:= 
lncl(sta. 
authOs) 



(auth_key) 



authKey:= 
lncl(sta. 
authKey) 



authKey:= 
Del(sta. 
authKey) 



(de_auth) 



authOS:= 
Oel(sta, 
authOs) 



authOS:= 
Del(sta. 
authOs) 



-5 



(dis_ 
asoc) 



authKey:= 
Del(sta. 
authKey) 



(false) 




sta in 
asoc 



[true) 



asoc:= 
Oel(sta. 
asoc) 



Deauthenticate 
of associated 
station causes 
disassociate 
at same time. 
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Process Power_Save_ Monitor 



ps_monitor_2a(2) 



Monitorjdle 



1 Power Save and Station State 
-■j query and response below, 
i monitoring on previous page. 



Pstnquiry 
(sta) 



1 Pslnquiry returns PsResponse to 
- -j report power mode awake, asleep, 
t or unknown at the target station. 




Sslnquiry 
(sta) 



(true) 



psrn:=! 
unknown 



(true) 






psm:= 
asleep 




i Sslnquiry returns SsResponse to report 
— — i station state not_auth, assoc. or dis_assoc: 
' and authentication state noLauth, 
i auth_open, or auth_key at the target station. 



(false) 



psm:= 
awake 



PsResponse 
(sta. psm) 
to sender 




(true) 



asst:- 
auth_open 



sta in^^\^ 







(true) 


assfcs 




auth_key 






asoc 
](tnje) 



(true) 



sst:= 
asoc 



(false) 



(false) 



asst:~ 
not auth 



1 When there is no association 
- -[ info, station state is identical 
i to authentication state. 



SsResponse 
(sta.sst.asst) 
to sender 
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Mop 



Process Mlme_AP_Services 



£m Im e Dea u th ent icate .con fi rm J 



apjv1m_svc_1b(1) 



/* Intra-MAC remote variables V 
del exported mAssoc Boolean— true, 
m&rates Octetstring:=mkOS(10.1), 
mBssId MacAddr:= dot1 1 MacAddress, 
mCap Octetstrtng:= 02. 
mCfp Boolean := false, 
mOisabte Boolean:= true. 
mDtimCount Integer = 0. 
dot1 1 DtimPeriod Integer— 1, 
mtbss Boolean:^ false, 
mNextBdry Time:= 0. 
mNextTbtt Time:= 0, 
doM 1 0perational RateSet Octetstring:= 

mkOS(10.1), 

mPcAvail Boolean: = sCfPollable. 
mPcPoll Boolean:= false, 
dot1 1 PowerManagementMode PwrSave:= 
sta_active, 

mPss PsState:= awake, 
mSsId Octetstring:= null : 



/* Each of these ovals represents a f\ 
SERVICE. Each service contains ^ 
the state transitions to handle a 
DISJOINT SUBSET of the input 
signal set of this process. Services 
share local variables and the input 
queue. At any instant, a state 
transition can occur in, at most, one 
service - the service which handles 
the kind of signal at the head of the 
process input queue. V 



MlmeAssociate. indication. 
MlmeDisassociate. confirm. 
MlmeDisassociate. indication. 
MlmeReassociate. indication 



MlmeAuthenticate. indication. 
MlmeDeauthenticate. indication 



MlmeStart. confirm 



rcis2err1 




ArqMop 



ArqDs 



MlmeDeauthenticate.. 
request 



As Mop 



AsocService_AP 



J^AsChangeJ 
^MmRequestJ 



AsCt 



Sst, 

Send, 

Xport 



DsTx 





AsDs . 


"Sst. 




Send. 




Xport 





AsocReq. ReasocReq, 
AsocRsp. ReasocRsp. 
Disasoc, Cls3err 



^MlmeDisassociate. requestj 
^DsResponseJ 



Arslnd 



^MmConftrmj 



Distribute. 
_Mmpdus 



DsSs 



[Sst. 
Send. 
Xport 



ArsDs 



StaStateJ 



I Mm_ 
Indicate | 

DsRx j 



fsend.l\ 
Xport 



[AuthOdd.] 
Deauth 



AuthRspService 



SyDs> 



Ds Inquiry, 
DsNotify 



DsDs 



SyCtl 



MmCanceU 
SwChnl 



ResetMAC ' 
handled by |- 
Sync service. i 



^SwDoneJ 



ProbeReq, 
ProbeRsp. 
Beacon. Cfend, 
Sent 



Synchronization 
_AP 



Timer Tauth. 
Tchal. Tbcn 



Signal 
AsocReq (Frame), 
AsocRsp(Frame), 
AuthOdd(Frame). 
Beacon(Frame.Time, 
Time), 
Cfend, 

Cls2err(MacAddr). 
Cls3err(MacAddr), 
Deauth(Frame), 
Disasoc( Frame), 
ProbeReq(Frame). 
ProbeRsp (Frame, 

Time. Time), 
ReasocReq(Frame), 
ReasocRsp(Frame). 
Send(Frame.lmed). 
Sent(Frame.TxStatus), 
Sst(MacAddr, 

StationState). 
Xport ; 



SyRx 
JchangeNavJ 



SyMop 



£m I m eSta rt. req uestj 



ToRx 
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Service AsocService_AP 



ap_disasoc_1b(2) 




r This service responds to K 
incoming Associate, and ^ 
Reassociate at the AP, and 
handles Disassociate requests 
from Mime and WM. This 
service also generates 
responses for class 3 errors. V 



del asCap Capability ; K 
del asRsn ReasonCode . 
del asSta MacAddr : 
del asSts TxResult : 
del asStat OsStatus : 
del asRdu. asSdu Frame 



1 On this page are Disassociate request 
-| incoming Disassociation frame, and 
i class 3 error. More on next page. 



C!s3err 
(asSta) 



MlmeDis^ 
associate., 
request 




<MlmeDis_ 
associate, 
indication 



(addr2(asRdu), 
reason(asRdu)) 



Sst(asSta. 
dis_asoc) 



AsChange 

(asRdu, 

disasoc) 



' Update station 
-•[state regarding 
i this association. 



' Remove association 
- \ data recorded for 
t this station. 



Xport 



asRsn:= 
class3_err 



(asSta. 
asRsn) 



asSdu:= 
mkFrame 
(disasoc. 



asSta. 

mBssid, 

asRsn) 



Send 




{asSdu. 




norm) 








Sst(asSta. 


dis_asoc) 




i Local station state 
- \ updated even if 
' notification frame 
i is undeliverable. 

1 Don't confirm 
--J class 3 error 
i notifications. 



<MlmeDis_ 
associate., 
confirm 



(successful) 
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Service AsocService_AP 



ap_asoc_reasoc_2a(2) 



Asocjdle 



AsocReq 
(asRdu) 



Dslnquiry 
(addr2(asRdu) 
mBssId) 



Wait_Asoc_ 
_Status 



OsResponse S 
( . .asStat) \ 




(disasoc, 
unknown ) 



save 
request 
info(Ald)' 



'make 
asoc_rsp 
(success)' 



else 



'make 
asoc rsp 
(fail)' 



DsNotify( 

addr2( 

asRdu). 



asStat) 



AsChange 

(asRdu. 

asStat) 



Send 

(asSdu, 

norm) 



| On this page are response to 
■-] associate and reassociate requests, 
i More of this state on previous page. 



1_ 



ReasocReq 
(asRdu) 



Dslnquiry 
(addr2(asRdu), 
mBssId) 



Wait_Reasoc, 
.Status 



OsResponse 
( . .asStat) 




asStat 
(asoc) 



assign 
Aid' 



save 
request 
info(Ald)' 



'make 
reasoc_rsp 
(success)* 



else 



'make 
reasoc_rsp 
(fail)' 



DsNotify( 

addr2( 

asRdu). 



reasoc) 



AsChange 

(asRdu. 

asStat) 



Send 

(asSdu. 

norm) 
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Service AuthReqService_AP 



ap_auth_req_1a(1) 



del auAlg AuthType : K 
del auCap Capability : ^ 
del auRdu. auSdu Frame 
del auRsn ReasonCode ; 
del auSta MacAddr : 
del auSts TxResult : 
dctauTmot Kusec ; 



/* This service handles K 
DeAuthenticate requests. ^ 
This service also handles 
incoming the generation of 
responses for class 2 errors 

This service does not 
do authenticate requests 
because APs never 
initiate authentication. V 



Auth_Req_ 
Idle 



Cls2err 
(auSta) 



MlmeDeau_ 
thenticate._ 
request 



asRsn:= 
class2_err 



(auSta. 
auRsn) 



auSdu:= 
mkFrame 
(deauth. 



auSta. 

mBssid. 

auRsn) 



Send 




(auSdu, 




norm) 


> 






SstfasSta. 


de_auth) 



' Send notification, 
- -j do not wait for 
i delivery confirmation. 



1 Update local stations state 
--] records. Sending deauth also 
i clears asoc state if present. 



If deauthenticating 
the current AP, or 
deauthenticating 
everyone, end the 
association (if 
any) by clearing 
mBssid and mAssoc. 




mAssoc:=false. 
mBssid:= 
nullAddr 
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Service AuthRspService 



auth_rsp_1b(2) 




/* This service handles 
incoming Authentication 
& Deauthentication frames. 



This state machine handles 
only a single shared key 
authentication challenge 
sequence at one time, which 
is the simplest case. It is 
possible to have several 
authentication responses in 
progress at once, provided 
the source stations are ail 
different. To allow multiple 
responses this state machine 
gets collapsed into one slate, 
with sequence state held in a 
variable. The local variables 
are replicated for each 
response, selected by 
req uest er station ad d res s . V 



imported dot1 1 Authentication Response. 
Timeout Kusec ; 



3 



i The chKey value used to 
-J generate challenge text is 

• arbitrary, and does not need 
| to be shared. However. 
» implement ens are advised 
) that the source of chKey 
> SHOULD NOT be one 
| of the WEP keys, because 

* the output of the PRNG 
| when using chKey is sent. 
' unencrypted, in the 
| challenge text field. 
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Service AuthRspService 



auth_rsp_2b(2) 



Wait.ChaL 
_Rsp 



Timeout while ' 
waiting is a [-- 
failed attempt. ( 




In the case of 
undecryptable 
response, assume 
Auth frame from 
expected source 
is sequence 3. 



i Update station 
-i state, deauth 
i clears asoc 
! if present. 



(3) 



<MlmeDeau_ 
thenticate._ 
indication 




{arSta3, 

reason 

(arRdu)) 



mAssoc:=false. 
mBssid:* 
nullAddr 



i If deauth is 
-.[from current 
i AP, end asoc 
| ('f any) by 
i clearing 
j mBssid and 
i mAssoc. 



Xport 




-£<^arChalng= 
(false) 

" (true) 



arSC:= 
chnlg_fail 



arSC:* 
successful 



Sst(arSta2. 
de_auth) 



Sst(arSta2, 
auth_key) 



arSdu:= 
mkFrame 
(auth, arSta. 



Send 

(arSdu, 

norm) 



Auth_Rsp_ 
_tdle 



AuthOdd 
(arRdu) 



1 



Tchal 



arSeq2:= 
authSeqNum 
(arRdu). 



arSta2:= 

addr2 

(arRdu) 




Sst(arSta. 
de_auth) 



arSeq2 
else 



(false) 



(1) 



Auth_Rsp_ 
J die 



i Open_system 
-J request from a 
' different station 
| can be handled 
i while awaiting 
| challenge rsp. 




imported ot1 1Authenti_ 
cationAlgorithms) 



arSC:= 
unspecjail 



T 




getElem 

(eCtxt 

arRdu) 



arSC:= 
unsupt_alg 




arSC:= 
successful 


) 






Sst(arSta2. \ 
de_auth) ? 


Sst(arSta. \ 
auth^open) ? 






I 


i 




arSdu:= 
mkFrame 
(auth,arSta2, 




mBssid, 

(authAlg 

(arRdu)) 

// mkOS 

(arSeq2+1, 

2)11 

arSC)) 








Send \^ 
(arSdu, y 
norm) / 









mBssid, 
(arAlg // 
mkOS(4,2) 
// arSC)) 



Wait_Chal_ 
_Rsp 



i Continue 
-J to wait for 
* response to 
J challenge. 



A station 
is allowed 
to reject an 
open system 
auth request 
with status 
unspecjail. 
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Service Distribute.Mmpdus 



mmpdu_svc_la(2) 



Re-export the 
intra-MAC 
remote 
variables to 
make updates 
available. 





mAtimW, mBssld. mCap.mCfp. 
m Disable, mlbss, mListenlnt, 
mNextBdry. mNextTbtt. mPcAvail. 
mPcDIvr. mPcPoll. dot11 Power. 
ManagementMode, mPss. mSsFd) 



/* This service routes N 
mmpdu and station stater 
update signals from and 
to the mime operational 
services. Signals are 
not modified, but some 
superfluous parameters 
are omitted in transfer. */ 




' The selection criteria for 
-I Mmpdu Tx data rate are 
' not specified. Frames 
| to group addresses must 

■ use one of the basic rates. 

| Requests should use one of 
■the basic rates unless the 
| operational rates of the 
• recipient station are known. 
| Responses must use a basic 

■ rate or the rate at which 

i the request was received. 



del mAdr MacAddr ; 
del mlm imed ; 
del pri CfPriority ; 
del mRate Rate : 
del mRpdu, mSpdu Frame 
del mSerr StateErr : 
del mSst Stati on St ate ; 
del mtE, mtT Time ; 
del mTxstat TxStatus : 
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Service Distribute_Mmpdus 



mmpdu_svc_ 1 . 1 b(2) 



Mmpdu_ 
Idle 



(cfend, cfend_ack) 



Cfend 



Mmpdu_ 
Idle 





(auth) 


mTst:= 


= mod( 


authSeqNum 


(mRpdu), 2) 





(0) 


AuthEven 




(mRpdu) 


< 




AuthOdd 
(mRpdu) 



(atim) 



Atim 
(mRpdu) 



(beacon) 



Beacon 
(mRpdu, 
mtE.mtT) 




Cls2Err 
(addr2 
(mRpdu)) 



(asoc_req) 



AsocReq 
(mRpdu) 



(reasoc_req) 



ReasocReq 
(mRpdu) 



(probe_req) 



X 



ProbeReq 
(mRpdu) 



(disasoc) 

n 



Disasoc 
(mRpdu) 



(class3) 



Cls3Err 

(addr2 

(mRpdu)) 



(asoc.rsp 



AsocRsp 
(mRpdu) 



(reasoc_rsp) 



ReasocRsp 
(mRpdu) 



(probe_rsp) 



ProbeRsp 

(mRpdu. 

mtE.mtT) 



(deauth) 



Deauth 
(mRpdu) 



Mmpdu_ 
Idle 
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Service Synchronization_AP 



apjnit_1b(3) 



del yAtimRx. yPsm. yRdtim, yWake Boolean ; IV 

del yAtw. y8cn, yMocp Time : ^ 

del yBcnPeriod. yDtim.ycmax. yemin Kusec : 

dclybd BssDscr; 

del ybdset BssDscrSet ; 

del ybtp BssType : 

del ybsrd MacAddr ; 

del yclist Intstring : 

del ycx, yJto. ytemp Integer ; 

del yDspm DsParms ; 

del yFhpm FhParms : 

del ylbpm IbssParms ; 

del ypdly Usee ; 



del yPhpm PhyParms : (\ 
del yRdu. yTdu Frame 
del yssid Octetstring : 
del yOrates Ratestring: 
del ystp ScanType ; 
del ytrsl TxResuit : 



timer Tscan, 
Tmocp ; 



3 



variables 
to default 
values' 



Set TSF 
time to 
zero. 



\>Res 


etMAC 






'obtain PHY 
characteristics' 






'reset all 
intra- MAC 
remote 






) 


yten 
call 
(O.t 


ip:= 
TSF 
rue) 



Xpert 



Setting these 
timers to now 
causes events 
in each of the 
multi-state 
services of the 
process, forcing 
each service to 
its idle state. 



reset(Tbcn), 
set(now,Tauth), 
set(now,Tchal) 



No.BSS 
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Service Synchronizatton_AP 



No.BSS 



> Start IBSS on 
— -J this page, join 
on next page. 



i Activate 
i Station 
i state 
| machine. 



(infrastructure) 










\ MlmeStart._ 

^request 
/ (mSsid. yBtp 




yBcnPeriod. 
yDtim. 

yCfpm. yPhpm, 
/* ibpm, V mCap, 
mB rates, y Orates) 





MlmeStart.. 

confirm 

(invalid) 



dot11Dtim_ 
Period:=yDtim. 



No.Bss 



export(dot11_ 
BeaconPeriod, 
dot1 1 DtimPeriod. 



yBcn:= kUsec( 
yBcnPeriod) 



mCf Avail™ 
if dtim_ 
Period 



'set mCfPoll 
and mCap for 
operating state' 



set aCfPeriod anc 
aCfM ax Duration 
from yCfpm' 



'set actual 
phy parameters 
from phpm' 



Xport 



station_active, 
mPss:=awake, 
dot1 1 Beacon. 
Period:= yBcnPeriod 



dot1 1 0perational. 
RateSet=y Orates 



dot1 1 0perational. 

RateSet,dot11Pow_ 

erManagementMode) 



(yCfpm) /= 0 
then true 
else false fi 



ap_Start_Bss_2b(3) 



( 


atse) 


yMocp:=kUsec 
(import(aMedium_ 
OccupancyLimit)) 






yMocp:=kUsec 
(dwell Time 
(yFhpm)) 




mNextBdry:s 
now+(yMocp 
- (call TSF 



(O.fafse) 
mod yMocp)) 



set 

(mNextBdry, 
Tmocp) 



i Initialize 
" "i dwell timer. 



'yChan:= 
first (or only) 
channel' 



i Set starting 
-.[channel (FH) 
i or operating 
[channel (DS), 
i null for IR. 



SwChnl 
(yChan.true) 



mNextTbtt™ 
now-»-(yBcn 
- (call TSF 



(O.false) 
mod yBcn)) 



set 
(mNextTbtt, 
Tbcn) 



j Initialize 
" *' beacon timer. 



Xport 



MlmeStart. 

conftrm 

(success) 



Bss 



454 



Copyright © 1999 IEEE. All rights reserved. 



MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS 



ISO/IEC 8802-11: 1999 (E) 
ANSI/IEEE 802.11, 1999 Edition 



Service Synchronization, AP 



ap_TSF_bss_3b(3) 



Tbcn 



set 

(now+yBcn, 
Tbcn) 



ytdu:= 
mkFrame 
(beacon. 



mDtimCount:= 
mDtimCount-1 




(false) T(true) 



yCfpm:= 
setCfpCount 
(yCfpm. 



Bss 



^>Cfe 


id 






mCfp 


=false 



ProbeReq 
(yRdu) 



bcstAddr. mBssId, 
08 /'timestamp 
inserted by tx */ 
// mk2octets( 
yBcnPeriod)// 
mCap// mkElem( 
eSstd.mSsId)// 
mkElem{eSupRates, 
yOrates)) 



ytdu:= 
mkFrame 
(probe_rsp, 



Xport 



Send 

(ytdu.norm) 



bcstAddr.mBssld. 
08 /'timestamp 
inserted by tx 7 
// mk2octets( 
yBcnPeriod)// 
mCap// mkElem( 
eSstd.mSsId)// 
mkElem(eCfp. 
yCfpm)// 

mkElem(eSupRates, 

yOrates)//mkElem( 

ePhpm.yPhpm)) 



mNextBdry" 
mNextBdry < 
yMocp 



set 

(mNextBdry. 
Tmocp) 



ytdu:= 




mkElem 




ytdu// 




(eCfp.yCfpm) 


(false) 









if yCfCnt=0 

then import (dot1 lCfpPeriod)-1 
else yCfCnt-1 ft) 




yCfpm:= 
setCfpPeriod 
(yCfpm, 



yCfpm:= 
setCfpMaxOur 
(yCfpm, 



'update 
cfOurRem 
and mCfp' 



'add proper 
phy parameter 
set element* 



Xport, 
Send 

(ytdu.imed) 



import 

(dotUCfpPeriod)) 



SwChnl 
( .false) 



import 

(dot1 ICfpMaxDuration)) 



> TIM element 
■--jgets added by., 
i PM_Filter_AP. 



SwChnl 
(yChan.true) 



Wait_Hop_ 
Bss 



SwDone 



Bss 
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PS 



Block Reception 



Includes decryption if 
dot1 1 PrivacyOptionlmplemented 
=true. This is a typical 
location, but impiementers 
may use other locations 
between the PHY_SAP_RX 
and MAC_SAP as long as 
they provide the specified 
behavior as observed at 
LLC. MLME and the WM. 



/* This block handles octet-level K 
reception of MPDUs from the ^ 
PHY. and validation, filtering, 
and decryption needed so higher 
blocks have uniform, error-free 
information from the relevant rx 
events. This block also maintains 
the MAC's view of channel state, 
including the NAV (and remote 
variable mNavEnd), rx activity 
(and the remote variable mRxA), 
and slot timing (providing the 
Busy. Idle and Slot signals to 
the Transmission block). V 



ToTx 



Busy, Idle, SlotJ 



PhyCca. indication, 
PhyCcarst.conftrm 



signal ClearNav(NavSrc), \ 
RtsTimeout, ^ 
RxM pd u(Frame, Time,Time, 

Rate, Boolean, 

Key Vector , KeyMa pArra y) , 
SetNav(Time, 

Duration .NavSrc), 
UseDifs(Time), 
UseEifs(Time) : 




receive. 1a{1) 



PhyRxStart.tndication, 
PhyRxEnd. indication, 
PhyData.indication 

FromPHY 



j^PhyCcarst.requestJ 



PHY_SAP_RX 
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Process Channel_State 



nav_dear_1b(2) 



dSifs:= 
dUsec 
(aSifsTime). 



dSlot:= 
dUsec 
(aSlotTime). 



dEifs:= 
dUsec 
(aSifsTime * 



dlfs:= 
dEifs 



cs:= busy, 
tNavEnd:=0 



et{Tnav) 



PhyCcarst._ 
request 



export 
(tNavEnd) 



curSrc:= 
nosrc 



Busy 



Cs_noNav 



dct exported 
tNavEnd as i 
mNavEnd Time : 



timer Tifs : 
timer Tnav ; 
timer Tslot : 



ResetMAC 



del cs CcaStatus : 
del rxtx. slot, sifs Integer ; 
del dDifs, dEifs. dlfs. dNav. 

dRxTx. dSifs. dSlot Duration 
del tNew. tRef. tRxEnd Time ; 
del newSrc, curSrc NavSrc : 



dRxTx:=dUsec 

(aRxTxTurn_ 

aroundTime) 



dDifs:=dSifs + 
(2 * dSlot) 



calcOur(first( 
import(mBrates)). 
stuff(aMpdu_ 
DurationFactor, 
sAckCtsLng) + 
aPlcpHdrLength 
+ a Preamble, 
Length) + dDifs) 



■ Assume channel 
- -J busy until Phy 
> indicates idle. 
] tNavEnd is =0 
• until first rx 
| that sets Nav. 



1 PhyCcareset.. 
- -J confirm is 
i ignored. 



PhyCca._ 
indication 
(cs) 




1 Eifs based 
-J on the lowest 
i basic rate. 



Wait IFS 
r IDLE 7 



1 ClearNav. RtsTimeout. 
-[ Tnav. Tslot ignored 
i in WaitJFS state. 




set 

(now+dSlot. 
Tslot) 



1 ClearNav, Tnav. Tifs, 
■j RtsTimeout. Tslot 
i ignored in this state. 



noCs_noNav 
/• IDLE 7 



> Idle signal is 
. \ sent at end of 
i the M2 interval 
| (Figure 47). 

i RtsTimeout 
- \ Tnav, ClearNav, 
i Tifs ignored 
| in this state. 



\ Sett 
>(tRe 
/ curS 


vlav 

f.dNav. 
>rc) 






tNavEnd:= 
tRef+dNav 






s 

(tNav 
Tn 


St 

End. 
av) 






> Slot signal is 
\ generated at 
i the end of each 
| M2 interval 
• (Fig. 47) while 
| channel is idle. 



r This process K 
maintains channer^ 
state based on 
both physical and 
virtual carrier 
sense, generates 
slot time reference, 
and provides Busy. 
Idle & Slot signals 
to Transmission. V 
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J 

I Process Channel. State 



nav_set_2c{2) 




Cs^Nav \ I 1 

/*BUSYV f~~V} 
I i c 



Tstot and Tifs 
ignored in 
i Cs_Nav state. 



curSrc:= 
nosrc 



(busy) 




Tnav 



PhyCcarst.. 
request 



curSrc:= 
nosrc 



set 
(now+dlfs, 
Tifs) 



set 
(now+dlfs. 
Tifs) 



WaiMFS 



Cs_noNav 



/* all states */ 



1 ChangeNav is 
-! SetNav if not 











UseEifs / 
(tRxEnd) 


UseDifs / 
(tRxEnd) 








dlfs:= 
dEifs-dRxTx 




dlfs:= 
dDtfs-dRxTx 






1 


( 




set 

(tRxEnd+dlfs, 
Tifs) 


Clear NAV and 
use EIFS after 
channel change. 


\ 







noCs^Nav. 

Cs Nav 
/* all NAV •/ 



• Clearing NAV on 
■ -| RTS timeout is 
i optional (9.2.5.4). 



i The initial dlfs tNavEnd is =0 ' 

\ value is dEifs, until first rx j- 

t set by a UseEifs 0 n new channel, i 

j signal generated J 

i by Validate_Mpdu 
J at startup and 
■ due to Reset MAC. 




CtearNav 
(newSrc) 



set(now.Tnav) 



(true) 



tNavEnd:= 
now. 
curSrc:= nosrc 



tNavEnd:=0. 
curSrc=nosrc 



Nav is cleared by setting Tnav i 
to now. This causes immediate {■ 
Tnav signal to enable exit from ' 
noCs_Nav or Cs_Nav state. \ 



set(tNavEnd, 
Tnav) 
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Process Validate.MPDU 



start_rx_lb(2) 



(Rxjdle) 



Calculate PHY 
Rx delay that 
is subtracted 
from now to 
get reference 
point times. 



01:= dUsec 
(aRxRfDelay* 
aRxPlcpDelay) 



ResetMAC 



reset(Trts) 



cErn=0, 
mRxA:=fa!se 



export 
(cErr.mRxA) 



/* This process receives an MPDU from the K 
PHY while calculating and checking the ^ 
FCS value. Frames with valid FCS. length 
and protocol version are sent for receive 
filtering, along with a snapshot of the WEP 
keys if dot11PrivacyOptionlmplernented=true, 

This process also provides Channel_State 

with Difs/Eifs and Rts timeout signals, 

and maintains the mRxA remote variable. V 



del exported mRxA Boolean:=false. 

cErr as dot11FcsErrorCount Counter32:= £ 
imported mBrates Ratestring. 

dot11WepDefaultKeys KeyVector. 

dot11WepKeyMappings KeyMapArray, 

dot1 1 Exclude Unencrypted Boolean: 
timer Trts ; 



1 Indicate Rts 
•j non-response 
i timeout. 



Rxjdle 



- -\ Trts 



PhyRxStart../ 


(rxLength. 


indication V 


rxRate) 



RtsTimeout 



reset (Trts) 



mRxA:=true 



< Indicate that 
- -] a reception 
i is in progress. 



export(mRxA) 



(false) 



Rx_Frame 




del fes Crc : 
del D1, dRts Duration ; 
del endRx. startTs Time : 
del k, rxLength Integer ; 
del pdu Frame ; 
del rxRate Rate ; 
del status PhyRxStat ; 
del v Octet ; 

del wDe fault Key Vector ; 
dclwKeyMap KeyMapArray 
del wExclude Boolean ; 



K 




wKeyMap:= 
import( 



wExclude: s 
import 



Rx_ Frame 



i Save copy of 
] WEP keys at 
i RxStart in case 
j Mpdu is first 
( fragment of 
| encrypted 
( Msdu/Mmpdu. 



dot11Wep_ 
DefaultKeys) 



dot1 1 Wep_ 
KeyMappings) 



(dot11 Exclude. 
Unencrypted) 
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Process Validated PDU 



validate_rx_2c(2) 



Rx_Frame 



Save lime of Rx 
r -| end as reference 
I for start of IFS. 



■ Save arrival time 
i of first octet of 
' (what may be a} 
| timestamp field. 



























PhyRxData._/ 
indication(v) \ 




Accumulate 
octet into Mpdu 
and CRC check. 


PhyRxEnd._ / 
indication ^ 
(status) \ 














pdu:= 
pdu// 
mkstring(v). 




fcs:= 

crc32(fcs, v) 


endRx:= 
now-D1 



(true) 



startTs:* 
now-D1 



(false) 



PhyOata. indicate 1 
ignored to drop ]- - 
excess octets, i 



Save time of Rx ' 
end as reference j- - - 
for start of IFS. i 



PhyRxEnd.. 

indication 

(status) 



endRx:= 
now-D1 



<UseEifs 
(endRx) 



mRxA:=false 



Indicate that > 
reception is |- 
not in progress, i 



export(mRxA) 



Rxjdle 



Rts timeout ' 
based on \ 
rate of Rts. t 




ftype(pdu) 



cErr:= 
inc(cErr) 




pdu:= substr 
(pdu, 0. 




(rxLength - 
sCrcLng)) 














export(cErr) 


/ UseDifs 
Nv (endRx) 


| i Drop FCS field from 
L -| frame before passing 
i up for filtering. 





(false) 




RxMpdu 




startTs. 


(pdu. 




rxRate, < 


endRx. 




..) 




RxMpdu 




startTs .rxRate, 


(pdu. 




wExclude.wDefautt, 


endRx, 




wKeyMap) 



i Eifs based 
\ on the lowest 
i basic rate. 
| Assumed to 
i be the first 
] element of 
i mBrates. 
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Process Filter_MPDU 



pre_filter_1d(4) 



del exported cDup as dotl IFrameDuplicateCount, 
cMc as dotl IMulticastReceivedFrameCount. 
cRx as dot 11 Received FragmentCount Counter32" 



0: 



dPsp:=dUsec( 
aSifsTime+calc_ 
Dur(first{impor1( 



mBrates)), 

stuff(aMpduDuration_ 
Factor, sAckCtsLng 
♦ aPlcpHdrLength) 
+ aPreambleLength)) 



imported mBrates Ratestring. K 
mBssid MacAddr. L 
mCfp Boolean. 

dot11GroupAddresses MacAddrSet. 
mlbss Boolean, 
mSsid Octetstring. 
aStationld MacAddr ; 



cache: = 
c!earTuple_ 
Cache(cache) 



Filterjdle 



> Reset Mac 



> Initialize tuple cache 
- \ for duplicate filtering, 
i Cache capacity is set 
, by "tupleCacheSize" 
• but a specific size 
|is not specified. 



del cache TupleCache : K 
del dup, myBss Boolean ; ^ 
del dNav. dPsp. dAck Duration 
del endRx, strTs Time ; 
del pdu Frame ; 
del rxRate Rate ; 
del sre NavSrc : 
del w Default KeyVector ; 
del wExdude Boolean : 
del wKeyMap KeyMapArray : 



RxMpdu 
(pdu. * 
endRx, 



startTs.rxRate, 

wExclude.wDefault. 

wKeyMap) 



dAck:= 
if (moreFrag 
(pdu) = 1) and 



Gather Power 
management 
info from all 
valid frames. 



(durlD(pdu) > 32767) 
then d(Jsec(dur1d(pdu)) 
else 0 ft 









/ Pslndicate 
/ (addr2(pdu). 




pwrmgt(pdu)) 








dNav:=dUsec 
(durld(pdu)), 
src:= misc 






i Non-AP. 
\ toDS=0 to 
< accept frame, 
! next page. 



j Frames with toOs-1 ignored by non-APs, 
"i except Duration/Id field for Nav update. 



/* This process filters valid received k 
frames by destination address, and ^ 
Bssld for group destination addresses. 
This process also maintains received 
pdu counters and the tuple cache for 
detecting duplicated unicast frames. 

Data and management frames which 
need acknowledgement cause a 
NeedAck signal to Protocol .Control 
as well as an RxMpdu to Defragment 
Piggybacked CfAcks cause RxCfack 
signals, and CfPolls cause RxCfpoll 
signals to Protocol .Control. If an 
RxCfPoll is sent for a Data+CfPoll 
or Data+CfPoll+CfAck. the NeedAck 
has to reach TxCoord during the Sifs. 
(The data frame report cannot serve 
this purpose because the payload may 
be a non-final fragment.) 

Duration and Cfp duration remaining 
are reported to Channel_State, and 
power save mode is reported to Mime. 7 
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Process Filter_MPDU 



filter_sta_2b(4) 
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Process Filter JvlPDU 



filter_ap_3a(4) 



All frames to ' 
AP are directed [-- 
except probe_req. i 



alse) 




> Receive probe 
.[request at AP 
i the same as at 
! Ibss station. 



import 

(dot11_ 

MacAddress) 



(false) 



(data.ack. 
cfend_ack, 
cfack) 



< 



else 



RxCfAck 
(addr2(pdu)) 



src:= if rts= 
ftype(pdu) then 
rts else src fi 




(probe.req) 



(beacon) 





dNav:= 
dUsec(cfDur_ 
Rem(pdu)) 



<ClearNav 
(cfend. 
Other) 

else 



SetNav 
(endRx.dNav 
cfpOther) 



T 



' Unsolicited 
- -| RxCfAck signals 
i should not occur. 




Filterjdle 



Nav to cover 
PS-Poll Ack 
when DurlD 
field is SID. 

Update Nav 
using value 
in Duration/ID 
field of frames 
directed to all 
other stations. 
Else case is for 
Ourld-32768 
in the CF period. 
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Process Filter_MPDU 



report_rx_4a(4) 




i Report incoming 
\ directed frames, 
i including all 
[ received frames 
i accepted at AP. 



/mm\ | Report incoming 

I cas( ~ f group-addressed 



i frames at station. 



Count at! valid 
directed frames 
to this sta. even 
those that will 
be discarded 
as duplicates 
or due to WEP. 



cRx:= inc(cRx) 



_L 



cRx:= inc(cRx). 
cMc:= inc(cMc) 



export(cRx) 



export 
(cRx. cMc) 



i Count all valid 
-,J broadcast and 
i multicast frames 
| to this sta. even 
i those that will 
1 be discarded 
! due to WEP. 













(=1) 




(=0) 


dup:= 




searchTupleCache 
(cache, addr2(pdu), 
seq(pdu). frag(pdu)) 






cDup:= 
inc(cDup) 



export(cOup) 



T 



(false) 



<^ftype(pdu)^>- 



(cfend. 
cfend_ack) 



RxMpdu 

(pdu. 

endRx, 



Ps-Poll is on 
else path (as 
control frame) 
to allow ack 
or data as the 
response from 
protocol ctl. 



New cache entry i 
if (addr2,seq) 
is not cached. 
If entry exists 
for (addrZseq), 
update time 
and fragment 
number of entry. 




startTs, 
rxRate, 
wExclude, 
w Default, 
wKeyMap) 



(data, management) 




1 Directed Atim frames must 
-- -| be acknowledged, but may be 
i omitted from cache, see 9.2.9. 



updateTupleCache 
(cache, addr2(pdu), 
seq(pdu).frag(pdu), 
endRx) 
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Process Defragment 



wep_filter_1b(3) 




del exported clerr as dot1 IWeplcvErrorCount. 
cUndc as dot1 IWepUndecryptableCount, 
cExcl as dotl 1 WepExcludedCount Counter32: 



3 



dLife:= 
dUsec( 
import 



(dot11Max_ 

Receive, 

Lifetime)) 



K 



imported mCfp Boolean : 
imported dotl 1 MaxReceiveLifetime Kusec 
imported procedure RC4 ; fpar PrngKey, Integer ; 
returns Octetstring ; 



export( 
clerr. cUndc. 
cExd) 



"J 



buf:= 
ArAge(buf. 
now+dLife+1) 



> Def ragmen tation 
- , buffers forced 
t empty using the 
i aging function. 



Defrag_ 
Inactive 



del buf Def rag Array ; K 

del dLife Duration ; L ^ 

del endRx. startTs Time : 

del icvOk Boolean : 

del k Defraglndex : 

del keys Def rag Keys Array : 

del pri CfPriority ; 

del pdu, sdu Frame ; 

del wExd Boolean : 

del w Default Key Vector : 

del wMap KeyMapArray : 



1 mDisable=false 



<not import \ , . t ^ . 
(mDisable) started 
'/ i or joined Bss. 





Rxlndicate 






(pdu. endRx. 




startTs.rxRate) 



auth) and 
authSeqNum 
(pdu)=3) and 
import( 

dotl 1 Privacy. 

Option, 

Implemented) 



(false) 
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Process Defragment 



wep_ decrypt. 2b (3) 




Decrypt 




wMap, sKey_ 


(pdu. 




MappingLength. 


icvOk, 




wDefault) 



» lev errors and 
i certain undecryptable 
1 errors counted in 
! Decrypt procedure. 




Do not report 
receipt of 
data frames 
with lev errors. 



Authentication 
challenge resposnes 
with lev errors 
are reported, but 
Decrypt removes 
payioad so Auth 
service is able 
to distinguish 
a bad key from 
a non-response. 



startTs.rxRate) 
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Process Defragment 




ind 



1 Mpdu is not fragmented 
-[ or defragmentation is 
i complete. 



x 



(true) 



Rxlndicate 






(pdu.endRx. 




startTs.rxRate) 





and 

(fragNum 
(Pdu)=0)) 



i Initial Mpdu 
.J of fragmented 
i Msdu. Find free 
J buffer to begin 
i Msdu reception. 



buf:= 




k:= 


arAge 
(buf.now). 




arFree(buf) 




(false) 



buf(k)!inUse:= 
false 



buf(k)!inUse:= 
true, 
buf(k)!rta:= 



addr2(pdu). 
buf(k)!rsn:= 
seqNum(pdu) 



buf(k)!rCur= 
fragNum(pdu), 
buf(k)!reol:= 



buf(k)!rCun= 
fragNum(pdu), 



(false) 



now ♦ kUsec( 
import(dot11_ 
Max Receive. 
Lifetime)) 




buf(k)! 
rsdu:=pdu, 




keys(k)! 
wOefKeys:= 

wOefautt, 
keys(k)! 
wKeyMap:= 

wMap, 
keys(k)! 
wExclude:= 

wExcl 



defragment_3c{3) 



' Intermediate or 
-| final Mpdu of 
i fragmented Msdu. 





buf(k)!rsdu:= 
buf(k)!rsdu // 
substr(pdu. 
sMacHdrLng. 
length(pdu)- 
sMacHdrLng) 



buf(k)!inUse:= 
false 



' Final fragment 
■[ if moreFrag=0, 
i indicate Msdu. 
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Procedure Decrypt 



decrypt. 1b{1) 



: fpar 

in/out pdu Frame, w 
in/out icvOk Boolean, 
in map KeyMapArray. 
in maplength 
KeyMapArrayLength. 
in kvec KeyVector : 



Concatenate < 
key with IV |-- 
from frame. i 



decryptLng) 



Use RC4 PRNG 
to generate an 
decrypt string 
as long as the 
MPDU payload 
plus the ICV 
field. 




tsWds:= 
toOs(pdu) and 
frDs(pdu) 



• Test whether addr4 
- -J field is present, 
i Only needed at AP. 



del icv Crc : 
del isWds Boolean : 
del decryptLng, k. n Integer 
del decryptStr Octetstring : 
dci key PrngKey : 
del kmap KeyMap : 



K 



decryptLng: 2 
length(pdu) - 
sMacHdrLng - 



sWepAddLng + 

sCrcLng - if isWds 

then sWdsAddLng else 0 ft 





(true) 


key:= 




kmap! 




wepKey 






if isWds then 
sWdsAddLng 
else 0 fi 



Decrypt by xor • 
of payload with [*-- 
decrypt string, i 



ICV test value ■ 
calculated from |- - 
decrypted data, i 



key:= kvec 
(keyld(pdu)) 



i Use default key 
- -| selected by 
i keyld value. 




key:= key // 
PrngKey! 
Iv(pdu) 



(data) 




cUndc:= 
inc(cUndc) 




basetype^- 
(Pdu) 



(management; 




k:= 0. 
n:= 

sWepHdrLng 



pdu(n):= 
pdu(n) xor 
decryptStr(k) 



icv:= crc32 
(icv, pdu(n)) 




ctern= 
inc(clerr) 



export(cUndc) 



export(clerr) 



pdu:- 
substr(pdu.O, 
sMacHdrLng) 



i If calculated 
-.jlCV not valid, 
t discard frame 
j body, and 
i report error. 



pdu:= 
substr(pdu,0, 
sMacHdrLng) 






icvOk 


= true 



icvOk:= false 




// substr(pdu. 
sWepHdrLng, 
decryptLng - 
sCrdng) 



i Remove ICV 
\ and IV fields 
i from MPDU. 
J report decrypt 
' success if ICV 
| result correct 
i or selected 
| key value null. 




468 



Copyright © 1999 IEEE. All rights reserved. 



ISO/IEC 8802-11: 1999(E) 

MEDIUM ACCESS CONTROL (MAC) AND PHYSICAL (PHY) SPECIFICATIONS ANSI/IEEE Std 802.11. 1999 Edition 

Annex D 

(normative) 

ASN.1 encoding of the MAC and PHY MIB 

-- * IEEE 802.11 Management Information Base 

IEEE802dotll-MIB DEFINITIONS BEGIN 
IMPORTS 

MODULE- IDENTITY, OBJECT -TYPE , 

NOTIFICATION- TYPE, Integer32, Counter32 FROM SNMPv2- SMI 
Displays t ring , MacAddress, RowStatus, 
TruthVaiue from SNMPv2-TC 

MODULE -COMPLIANCE, OBJECT -GROUP, 

NOTIFICATION- GROUP FROM SNMPv2-CONF 

if Index FROM RFC1213-MIB; 

***********************★**********+***#**************+************+*** 

-- * MODULE IDENTITY 

__ a************************************** **********★*****★★*★**+******+* 

ieee802dotll MODULE- IDENTITY 
LAST - UPDATED "9807080000Z" 
ORGANIZATION "IEEE 802.11" 
CONTACT -INFO 

"WG E-mail: stds-802-ll@ieee.org 

Chair: Vic Hayes 
Postal: Lucent Technologies, Inc. 
Zadelstede 1-10 
Nieuwegein, Netherlands 
3431 JZ 
Tel: ^31 30 609 7528 
Fax: ^31 30 231 6233 
E-mail: vichayes@lucent.com 

Editor: Bob O'Hara 

Postal: Informed Technology, Inc. 

1750 Nantucket Circle, Suite 138 
Santa Clara, CA 95054 USA 
Tel: +1 408 986 9596 
Fax: +1 408 727 2654 
E-mail: bobOinformed-technology.com" 

DESCRIPTION 

"The MIB module for IEEE 802.11 entities. 

iso(l) .member- body (2) .us (840) . ieee802dotll (10036) " 
: := { 1 2 840 10036 .} 

_. 

-- * Major sections 

**************************************#**#*******#*★**★#+************* 

-- Station ManagemenT (SMT) Attributes 

-- DEFINED AS "The SMT object class provides the necessary support at the 

-- station to manage the processes in the station such that the 

-- station may work cooperatively as a part of an IEEE 802.11 network."; 
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dotllsmt OBJECT IDENTIFIER 



: := {ieee802dotll l) 



dotllsmt GROUPS 

dot UStat ionConf igTable 

dot llAuthenti cat ionAlgorithms Table 

dot 1 lWEPDef aul t KeysTable 

dotllWEPKeyMappingsTable 

dot 1 lPr i vacyTable 

dotllSMTnotif ication 



{dotllsmt 1} 

{dotllsmt 2} 

{dotllsmt 3} 

{dotllsmt 4} 

{dotllsmt 5} 

{dotllsmt 6} 



MAC Attributes 

DEFINED AS "The MAC object class provides the necessary support 
— for the access control, generation, and verification of frame check 
-- sequences, and proper delivery of valid data to upper layers."; 



dotllmac OBJECT IDENTIFIER 



fieee802dotll 2 



-- MAC GROUPS 

-- reference IEEE Std 802. IF- 1993 
-- dot llOpe rationTable 
dotllCountersTable 
dotllGroupAddressesTable 

Resource Type ID 

dotllres OBJECT IDENTIFIER 

dot llresAt tribute OBJECT IDENTIFIER 



= {dotllmac 1} 
= {dotllmac 2} 
= {dotllmac 3} 



{ieee802dotll 3} 
{dotllres 1 } 



PHY Attributes 

DEFINED AS "The PHY object class provides the necessary support 
-- for required PHY operational information that may vary from PHY 
- - to PHY and from STA to STA to be communicated to upper layers . " 



dotllphy OBJECT IDENTIFIER 

phy GROUPS 
-- dot llPhyOpe rationTable 
-- dotllPhyAntennaTable 
- - do t 1 1 PhyTxPowerTable 

dotllPhyFHSSTable 

dotllPhyDSSSTable 
-- dotllPhylRTable 
-- dotllRegDomainsSupportedTable 

do 1 1 lAnt ennas Li s tTable 
-- dotllSupportedDataRatesTxTable 
-- dotllSupportedDataRatesRxTable 



{ieee802dotll 4} 



{dotllphy 1} 
{dotllphy 2} 
{dotllphy 3} 
{dotllphy 4} 
{dotllphy 5} 
{dotllphy 6} 
{dotllphy 7} 
{dotllphy 8} 
{dotllphy 9} 
{dotllphy 10} 



-- * Textual conventions from 802 definitions 

__ ***★+★*******+★********★*★★*+********★************++**** ***+*★*★★***#* 

WEPKeytype : := OCTET STRING (SIZE (5)) 

__ A*********************************** a********************************* 

-- * MIB attribute OBJECT-TYPE definitions follow 
**★**++**+★#★***+★**★★********* 

****************** + *********#*#*+********* + ** + ****** + ** i n MMMM n t + 1MH n MHt + 

-- * SMT Station Config Table 
__ 

dot 11 StationConf igTable OBJECT- TYPE 
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SYNTAX SEQUENCE OF DotllStationConf igEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Station Configuration attributes. In tabluiar form to 
allow for multiple instances on an agent . " 
: := { dotllsmt 1 } 

dot 1 IS tationConf igEntry OBJECT- TYPE 

SYNTAX DotllStationConf igEntry 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllStationConf igTable . It is 
possible for there to be multiple IEEE 802.11 interfaces 
on one agent, each with its unique MAC address. y The 
relationship between an IEEE 802.11 interface and an 
interface in the context of the Internet -standard MIB is 
one-to-one. As such, the value of an if Index object 
instance can be directly used to identify corresponding 
instances of the objects defined herein. 

if Index - Each 802.11 interface is represented by an 

if En try. Interface tables in this MIB module are indexed 

by if Index. " 



INDEX {if Index} 

{ dot US tationConf igTable 1 } 

DotllStationConf igEntry 
SEQUENCE { 



LIStationID 


MacAddress , 


dot 1 lMediumOccupancyL imi t 


INTEGER, 


dotllCFPollable 


TruthValue , 


dotllCFPPeriod 


INTEGER, 


dot 1 lCFPMaxDura t ion 


INTEGER, 


dotllAuthenticationResponseTimeOut 


INTEGER, 


dotllPrivacyOptionlmplemented 


TruthValue , 


do 1 1 1 Powe rManagement Mode 


INTEGER, 


dotllDesiredSSID 


OCTET STRING, 


dot 1 IDesi redBSSType 


INTEGER, 


dotllOperationalRateSet 


OCTET STRING, 


dot 1 IBeaconPeriod 


INTEGER, 


dotllDTIMPeriod 


INTEGER, 


dotllAssociationResponseTimeOut 


INTEGER, 


dotllDisassociateReason 


INTEGER, 


dotllDisassociateStation 


MacAddress, 


dotllDeauthenticateReason 


INTEGER, 


dotllDeauthenticateStation 


MacAddress, 


dot HAuthenticateFailStatus 


INTEGER, 


dotllAuthenticateFailStation 


MacAddress } 



dotllStationID OBJECT-TYPE 
SYNTAX MacAddress ■ 
MAX- ACCESS read -write 
STATUS deprecated 
DESCRIPTION 

"The purpose of dotllStationID is to allow a manager to identify 
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a station for its own purposes. This attribute provides 
for that eventuality while keeping the true MAC address 
independent. Its syntax is MacAddress. The default value 
is the station's assigned, unique MAC address." 

::= { dotllStationConf igEntry 1 } 

dot HMediumOccupancyLimit OBJECT- TYPE 
SYNTAX INTEGER (0..1000) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute shall indicate the maximum amount of time, 
in TU, that a point coordinator may control the usage of 
the wireless medium without relinquishing control for long 
enough to allow at least one instance of DCF access to the 
medium. The default value of this attribute shall be 100, 
and the maximum value shall be 1000." 

::= { dotllStationConf igEntry 2 } 

dotllCFPollable OBJECT- TYPE 
SYNTAX TruthValue 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"When this attribute is true, it shall indicate that the STA 
is able to respond to a CF-Poll with a data frame within a 
SIFS time. This attribute shall be false if the STA is not 
able to respond to a CF-Poll with a data frame within a SIFS 
time. " 

::= { dotllStationConf igEntry 3 } 

dot 11CFP Period OBJECT- TYPE 

SYNTAX INTEGER (0..255) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"The attribute shall describe the number of DTIM intervals 
between the start of CFPs. It is modified by 
MLME-START. request primitive." 

::= { dotllStationConf igEntry 4 } 

dotllCFPMaxDuration OBJECT -TYPE 

SYNTAX INTEGER (0.. 65535) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

' "The attribute shall describe the maximum duration of the CFP 
in TU that may be generated by the PCF. It is modified by 
MLME-START. request primitive." 

::= { dotllStationConf igEntry 5 } 

dot llAuthent icat ionResponseTimeOut OBJECT- TYPE 
SYNTAX INTEGER ( 1 . .4294967295 ) 
MAX-ACCESS read-write 
STATUS current 
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DESCRIPTION 

"This attribute shall specify the number of TUs that a 
responding STA should wait for the next frame in the 
authentication sequence." 

::= { dotllStationConf igEntry 6 } 

dot UPrivacyOpt ion Implemented OBJECT -TYPE 
SYNTAX TruthValue 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This attribute, when true, shall indicate that the IEEE 
802.11 WEP option is implemented. The default value of 
this attribute shall be false." 

::= { dotllStationConf igEntry 7 } 

dot UPowerManagementMode OBJECT -TYPE 

SYNTAX INTEGER { active (1), powersave(2) } 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute shall specify the power management 
mode of the STA. When set to active, it shall indicate 
that the station is not in power-save mode. When set 
to powersave, it shall indicate that the station is 
in power -save mode. The power management mode is 
transmitted in all frames according to the rules 
in 7.1.3.1.7." 
::= { dotllStationConf igEntry 8 } 

dotllDesiredSSID OBJECT- TYPE 

SYNTAX OCTET STRING (SIZE(0 . . 32) ) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute reflects the Service Set ID used 
in the DesiredSSID parameter of the most recent 
MI/1E_S can. request . This value may be modified 
by an external management entity and used by the 
local SME to make decisions about the Scanning process . " 
: := { dotllStationConf igEntry 9 } 

dotllDesiredBSSType OBJECT-TYPE 

SYNTAX INTEGER { infrastructure (1) , independent (2) , any (3) } 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

."This attribute shall specify the type of BSS the 
station shall use when scanning for a BSS with which 
to synchronize. This value is used to filter Probe 
Response frames and Beacons. When set to infrastructure, 
the station shall only synchronize with a BSS whose 
Capability Information field has the ESS subfieid set 
to 1. When set to independent, the station shall only 
synchronize with a BSS whose Capability Information 
'field has the IBSS subfieid set to 1. When set to 
any, the station may synchronize to either type of 
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BSS . " 

: := { dotllStationConf igEntry 10 } 

dot 1 lOperat ionalRa teSet OBJECT- TYPE 

SYNTAX OCTET STRING (SIZE (1 126) ) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute shall specify the set of data rates 
at which the station may transmit data. Each octet 
contains a value representing a rate. Each rate 
shall be within the range from 2 to 127, 
corresponding to data rates in increments of 
500 kb/s from 1 Mbit/s to 63.5 Mbit/s, and shall be 
supported (as indicated in the supported rates 
table) for receiving data. This value is reported in 
transmitted Beacon, Probe Request, Probe Response, 
Association Request, Association Response, 
Reassociation Request, and Reassociation Response 
frames, and is used to determine whether a BSS 
with which the station desires to synchronize is 
suitable. It is also used when starting a BSS, 
as specified in 10.3." 
::= { dotllStationConf igEntry 11 } 

dotllBeaconPeriod OBJECT -TYPE 

SYNTAX INTEGER (1.. 65535) 
MAX -ACCESS read -write 
STATUS current 
DESCRIPTION 

"This attribute shall specify the number of TUs that a 
station shall use for scheduling Beacon transmissions. 
This value is transmitted in Beacon and Probe Response 
frames." 
{ dotllStationConf igEntry 12 } 

dotllDTIMPeriod OBJECT- TYPE 

SYNTAX INTEGER ( 1 . .255) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute shall specify the number of beacon 
intervals that shall elapse between transmission of 
Beacons frames containing a TIM element whose DTIM 
Count field is 0 . This value is transmitted in 
the DTIM Period field of Beacon frames." 
::= { dotllStationConf igEntry 13 } 

dotllAssociationResponseTimeOut OBJECT- TYPE 
SYNTAX INTEGER U, .4294967295) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute shall specify the number of TUs that a 
requesting STA should wait for a response to a 
transmitted association- request MMPDU." 
::= { dotllStationConfigEntry 14 } 

dotllDisassociateReason OBJECT- TYPE 
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SYNTAX INTEGER (0 . . 65535 ) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This attribute holds the most recently transmitted 
Reason Code in a Disassociation frame. If no 
Disassociation frame has been transmitted, 
the value of this attribute shall be 0." 

REFERENCE "ISO/IEC 8802-11:1999, 7.3.1.7" 
::= { dotllStationConf igEntry 15 } 

dotllDisassociateStation OBJECT- TYPE 
SYNTAX MacAddress 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This attribute holds the MAC address from the 
Address 1 field of the most recently transmitted 
Disassociation frame. If no Disassociation frame has 
been transmitted, the value of this attribute 
shall be 0 . " 
::= { dotllStationConf igEntry 16 } 

dotllDeauthenticateReason OBJECT- TYPE 
SYNTAX INTEGER (0 . . 65535) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This attribute holds the most recently 

transmitted Reason Code in a Deauthentication frame. 

If no Deauthentication frame has been transmitted, the 

value of this attribute shall be 0." 

REFERENCE "ISO/IEC 8802-11:1999, 7.3.1.7" 
::= { dotllStationConf igEntry 17 } 

dot UDeauthent icateStat ion OBJECT-TYPE 
SYNTAX MacAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This attribute holds the MAC address from the Address 1 
field of the most recently transmitted Deauthentication frame. 
If no Deauthentication frame has been transmitted, 
the value of this attribute shall be 0." 
::» { dotllStationConf igEntry 18 } 

dotllAuthenticateFailStatus OBJECT -TYPE 
SYNTAX .INTEGER (0 . .65535) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This attribute holds the most recently 

transmitted Status Code in a failed Authentication frame. 
If no failed Authentication frame has been transmitted, the 
value of this attribute shall be 0." 

REFERENCE "ISO/IEC 8802-11:1999, 7.3.1.9" 
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::= { dotllStationConf igEntry 19 } 

dotllAuthenticateFailStation OBJECT-TYPE 
SYNTAX Mac Address 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This attribute holds the MAC address from the 
Address 1 field of the most recently transmitted 
failed Authentication frame. If no failed Authentication 
frame has been transmitted, the value of this attribute 
shall be 0." 
'::= { dotllStationConf igEntry 20 } 



__ ****************************************************************+*++*+ 

-- * End of dotllStationConf ig TABLE 

__ ******************************************** ************************** 

********************************************************************** 

-- * AuthenticationAlgorithms TABLE 

__ ***************************************************************+*+++*+ 

dotllAuthenticationAlgorithmsTable OBJECT- TYPE 

SYNTAX SEQUENCE OF DotllAuthenticationAlgorithmsEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"This (conceptual) table of attributes shall be a set of 
all the authentication algorithms supported by the 
stations. The following are the default values and the 
associated algorithm: 

Value = 1: Open System 
Value = 2: Shared Key" 
REFERENCE "ISO/IEC 8802-11:1999, 7.3.1.1" 
: :.= { dotllsmt 2 } 

dot 11 AuthenticationAlgorithms En try OBJECT -TYPE 

SYNTAX DotllAuthenticationAlgorithmsEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An Entry (conceptual row) in the Authentication 
Algorithms Table. 

if Index - Each 802.11 interface is represented by an 
ifEntry. Interface tables in this MIB module are indexed 
by if Index. " 

INDEX { if Index, 

do 1 1 1 Au then t i c a t i onAlgo r i thms I ndex } 
::= { dotllAuthenticationAlgorithmsTable ' 1 } 

DotllAuthenticationAlgorithmsEntry : : = SEQUENCE { 

dot llAuthenticationAlgori thms Index Integer32 , 

dotllAuthenticationAlgorithm INTEGER, 

dotllAuthenticationAlgorithmsEnable TruthValue } 



dot llAuthenti cat ionAlgorithms Index OBJECT-TYPE 
SYNTAX Integer3 2 
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MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"The auxiliary variable used to identify instances 
of the columnar objects in the Authentication Algorithms Table." 
::= { dotllAuthenticationAlgorithmsEntry 1 } 

dotllAuthenticationAlgorithm OBJECT- TYPE 

SYNTAX INTEGER { openSystem (1), sharedKey (2) } 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This attribute shall be a set of all the authentication 
algorithms supported by the STAs. The following are the 
default values and the associated algorithm. 
Value = l: Open System 
Value = 2: Shared Key" 

: := { dot lLAu then ticationAlgorithmsEntry 2 } 

dotllAuthenticationAlgorithmsEnable OBJECT- TYPE 
SYNTAX TruthValue 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute, when true at a station, 

shall enable the acceptance of the authentication 

algorithm described in the corresponding table 

entry in authentication frames received by the 

station that have odd authentication sequence numbers. 

The default value of this attribute shall be 1 for 

the Open System table entry and 2 for all other table entries." 

::= { do tllAuthenticationAlgorithms Entry 3 } 

a-********************************* ************************************ 

-- * End of AuthenticationAlgorithms TABLE 

*******★**********★****************#*****★**★*★*********#************* 

*********★**+********+★****★##******★*#*****★**********#+***+********* 

* WEPDefaultKeys TABLE 
_ _ *+*+***********★*******★********#****★*************************#****** 

dotllWEPDefaultKeysTable OBJECT-TYPE 

SYNTAX SEQUENCE OP Do tllWEPDe fault Keys En try 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Conceptual table for WEP default keys. This table shall 
contain the four WEP default secret key values 
corresponding to the four possible KeylD values. The WEP 
default secret keys are logically WRITE -ONLY . Attempts to 
read the entries in this table shall return unsuccessful 
status and values of null or zero. The default value of 
each WEP default key shall be null." 

REFERENCE "ISO/IEC 8802-11:1999, 8.3.2" 
: { dotllsmt 3 } 

dotllWEPDefauitKeysEntry OBJECT- TYPE 
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SYNTAX Dot HWEPDefauItKeys Entry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An Entry (conceptual row) in the WEP Default Keys Table. 

if Index - Each 802.11 interface is represented by an 

if Entry. Interface tables in this MIB module are indexed 

by i f Index . " 

INDEX {if Index, do tllWEPDe fault Key Index) 
::= { dotllWEPDefaultKeysTable 1 } 

DotllWEPDefaultKeysEntry : := SEQUENCE { 

dot 1 lWEPDef aultKeylndex INTEGER , 
dotllWEPDefaultKeyValue WEPKeytype} 

dot llWEPDe fault Key Index OBJECT- TYPE 
SYNTAX INTEGER (1..4) 
MAX-ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"The auxiliary variable used to identify instances 
of the columnar objects in the WEP Default Keys Table. 
The value of this variable is equal to the WEPDef aultKeylD - 1" 
::= { dotllWEPDefaultKeysEntry 1 } 

dotllWEPDefaultKeyValue OBJECT- TYPE 
SYNTAX WEPKeytype 
MAX -ACCESS. read-write 
STATUS current 
DESCRIPTION 

"A WEP default secret key value . " 
::= { dotllWEPDefaultKeysEntry 2 } 

*******★*****+***★**********★*******★★★**★#*****★***************+*+**+ 

-- * End of WEPDef aultKeys TABLE 

*★*******★*★★****+***★★**★*****+★★**++**★★★★★*****+*★**★********#*++** 



-- * WEPKeyMappings TABLE 

__ *+*+++**★★**+***+++★***** ********************* ***★★★*******★★***+*★*★* 

dotllWEPKeyMappingsTable OBJECT -TYPE 

SYNTAX SEQUENCE OF Do tllWEPKeyMappings Entry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Conceptual table for WEP Key Mappings. The MIB supports 
the ability to share a separate WEP key for each RA/TA 
pair. The.. Key Mappings Table contains zero or one entry 
for each MAC address and contains two fields for each 
entry: WEPOn and the corresponding WEP key. The WEP key 
mappings are logically WRITE-ONLY. Attempts to read the 
entries in this table shall return unsuccessful status and 
values of null or zero. The default value for all WEPOn 
fields is false. " 
REFERENCE "ISO/IEC 8802-11:1999, 8.3.2" 
: :» { dotllsmt 4 } 
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dotllWEPKeyMappingsEntry OBJECT -TYPE 

SYNTAX DotllWEPKeyMappingsEntry 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An Entry (conceptual row) in the WEP Key Mappings Table. 

if Index - Each 802.11 interface is represented by an 

if Entry. Interface tables in this MIB module are indexed 

by if Index. " 

INDEX {if Index, do tllWEPKeyMapping Index) 
{ dotllWEPKeyMappingsTable 1 } 

DotllWEPKeyMappingsEntry : := SEQUENCE { 

dotllWEPKeyMappinglndex Integer 3 2 , 

dotllWEPKeyMappingAddress MacAddress, 

dotllWEPKeyMappingWEPOn TruthValue, 

dot 1 lWEPKeyMappingVaiue WEPKeytype , 

dotllWEPKeyMappingStatus RowStatus } 

dotllWEPKeyMappinglndex OBJECT-TYPE 
SYNTAX Integer32 
MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"The auxiliary variable used to identify instances 
of the columnar objects in the WEP Key Mappings Table." 
::= { dotllWEPKeyMappingsEntry 1 ) 

dotllWEPKeyMappingAddress OBJECT-TYPE 
SYNTAX MacAddress 
MAX -ACCESS read- create 
STATUS current 
DESCRIPTION 

"The MAC address of the STA for which the values from this 
key mapping entry are to be used." 
::= { dotllWEPKeyMappingsEntry 2 } 

dotllWEPKeyMappingWEPOn OBJECT -TYPE 
SYNTAX TruthValue 
MAX -ACCESS read- create 
STATUS current 
DESCRIPTION 

"Boolean as to whether WEP is to be used when communicating 
with the dotllWEPKeyMappingAddress STA. " 
::=* { dotllWEPKeyMappingsEntry 3 } 

dot 1 lWEPKeyMappingVaiue OBJECT- TYPE 
SYNTAX WEPKeytype 
MAX -ACCESS read- create 
STATUS current 
DESCRIPTION 

"A WEP secret key value." 
::= { dotllWEPKeyMappingsEntry 4 } 

dotllWEPKeyMappingStatus OBJECT -TYPE 
SYNTAX RowStatus 
MAX -ACCESS read-create 
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STATUS current 
DESCRIPTION 

"The status column used for creating, modifying, and 
deleting instances of the columnar objects in the WEP key 
mapping Table." 

DEFVAL {active} 
::= { dotllWEPKeyMappingsEntry 5 } 

- - * End of WEPKeyMappings TABLE 

__ ****★★**+**★★★**'****+************★***#***********#+****+ 

-- * dotllPrivacyTable TABLE 

- _ *******+***★****+*★***************★**+******** ****##******++***^n M nnnn f 

dotllPrivacyTable OBJECT- TYPE 

SYNTAX SEQUENCE OF DotllPrivacyEntry 
MAX -ACCESS not- accessible 
STATUS current 
DESCRIPTION 

"Group containing attributes concerned with IEEE 8 02.11 
Privacy. Created as a table to allow multiple 
instantiations on an agent." 

: := { dotllsmt 5 } 

dotllPrivacyEntry OBJECT -TYPE 

SYNTAX DotllPrivacyEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllPrivacyTable Table. 

if Index - Each 802.11 interface is represented by an 
if Entry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index) 
::= { dotllPrivacyTable 1 } 

DotllPrivacyEntry : := SEQUENCE { 
dot 11 Privacylnvoked 
dotllWEPDefaultKeylD 
dot 1 1 WEPKeyMapp ingLengt h 
dot 1 1 Exc ludeUnencryp t ed 
dotllWEPICVErrorCount 
dot HWEPExcludedCount 

dotllPrivacylnvoked OBJECT -TYPE 
SYNTAX- TruthVa-lue 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"When this attribute is true, it shall indicate that the IEEE 
802.11 WEP mechanism is used for transmitting frames of type 
Data. The default value of this attribute shall be false." 
: := { dotllPrivacyEntry 1 } 

dotllWEPDefaultKeylD OBJECT -TYPE 



TruthValue, 

INTEGER, 

INTEGER, 

TruthValue, 

Counter32, 

Counter32} 
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SYNTAX INTEGER (0. .3) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute shall indicate the use of the first, 
second, third, or fourth element of the WEPDefaultKeys 
array when set to values of zero, one, two, or three. The 
default value of this attribute shall be 0." 
REFERENCE "ISO/IEC 8802-11:1999, 8.3.2" 
: := { dotllPrivacyEntry 2 } 

dot 1 lWEPKeyMappingLength OBJECT- TYPE 

SYNTAX INTEGER ( 10 .. 4294967295 ) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The maximum number of tuples that dotllWEPKeyMappings can hold." 
REFERENCE "ISO/IEC 8802-11:1999, 8.3.2" 
: := { dotllPrivacyEntry 3 } 

dotllExcludeUnencrypted OBJECT -TYPE 
SYNTAX TruthValue 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"When this attribute is true, the STA shall not indicate at 
the MAC service interface received MSDUs that have the WEP 
subfield of the Frame Control field equal to zero. When this 
attribute is false, the STA may accept MSDUs that have the WEP 
subfield of the Frame Control field equal to zero. The default 
value of this attribute shall be false." 

:i~ { dotllPrivacyEntry 4 } 

dotllWEPICVErrorCount OBJECT- TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when a frame is received with the 
WEP subfield of the Frame Control field set to one and the value 
of the ICV as received in the frame does not match the ICV value 
that is calculated for the contents of the received frame." 
::= { dotllPrivacyEntry 5 } 

dotllWEPExcludedCount OBJECT -TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS, current. 
DESCRIPTION 

"This counter shall increment when a frame is received with the 
WEP subfield of the Frame Control field set to zero and the value 
of dotllExcludeUnencrypted causes that frame to be discarded." 
: := { dotllPrivacyEntry 6 } 

__ ***************************************************** ***************** 

-- * End of dotllPrivacy TABLE 

***************************************************************++*+*** 
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******** ***************************************************** ********* 

-- * SMT notification Objects 

****************************************+**************+*+*********+** 

dotllSMTnotif ication OBJECT IDENTIFIER : := { dotllsmt 6 } 

dotllDisassociate NOTIF I CATION- TYPE 

OBJECTS { if Index, dotllDisassociateReason, 
dotllDisassociateStation } 
STATUS current 
DESCRIPTION 

"The disassociate notification shall be sent when the STA 
sends a Disassociation frame. The value of the notification 
shall include the MAC address of the MAC to which the 
Disassociation frame was sent and the reason for 
the disassociation. 

if Index - Each 802.11 interface is represented by an 
ifEntry. Interface tables in this MIB module are indexed 
by if Index. " 

::= { dotllSMTnotif ication 0 1 } 

dot 1 IDeauthent icat e NOTI FI CATION- TYPE 

OBJECTS { if Index, do tl IDeauthent icateReason, 
dot 1 IDeauthent icateS tat ion } 
STATUS current 
DESCRIPTION 

"The deauthenticate notification shall be sent when the STA 
sends a Deauthent icat ion frame. The value of the notification 
shall include the MAC address of the MAC to which the 
Deauthentication frame was sent and the reason for the 
dea u t hen t i c a t i on . 

if Index - Each 802.11 interface is represented by an 

if Entry. Interface tables in this MIB module are indexed 

by if Index." 

: := { dotllSMTnotif ication 0 2} 

dot HAuthent icat eFail NOTIF I CAT ION -TYPE 

OBJECTS { if Index, dotllAuthenticateFailStatus, 
dot llAuthenticate Fails tat ion } 
STATUS current 
DESCRIPTION 

"The authenticate failure notification shall be sent 
when the -STA sends an Authentication frame with a 
status code other than * successful . ' The value of 
the notification shall include the MAC address of the 
■MAC to which the Authentication frame was sent and the 
reason for the authentication failure. 

if Index - Each 802.11 interface is represented by an 
ifEntry. Interface .tables in this MIB module are indexed 
by if Index . " 

: := { dotllSMTnotif icat ion 0 3 } 
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********************++*+*************************************+*+++++++ 

-- * End of SMT notification Objects 

********************************************************* ************* 

- _ ****************************************************** + i [ i r + 1r1t + 4riririr i [ir1 ,+ + 

-- * MAC Attribute Templates 

__ ***********************************************+***+*++++ ************* 

**********************************************************i,t********** 

-- * dotllOperationTabie TABLE 

********** ************************************ *********** iritiritir ******** 

dotllOperationTabie OBJECT -TYPE 

SYNTAX SEQUENCE OF DotllOperationEntry 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Group contains MAC attributes pertaining to the operation 
of the MAC. This has been implemented as a table in order 
to allow for multiple instantiations on an agent." 

: { dotllmac 1 } 

dotllOperationEntry OBJECT-TYPE 

SYNTAX DotllOperationEntry 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllOperationEntry Table. 

if Index - Each 802.11 interface is represented by an 
if Entry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index} 
::= { dotllOperationTabie 1 } 

DotllOperationEntry ::= SEQUENCE { 
dotllMACAddress 
dotllRTSThreshold 
dotllShortRetryLimit 
do t 1 1 LongRe t ryLimi t 
dotllF ragmen ta t i onThr e shold 
dot 1 IMaxTransmitMSDULi f e t ime 
dot 1 lMaxRece iveLif e time 
dotl IManuf acturerlD 
dotllProductID 



dotllMACAddress OBJECT- TYPE 
SYNTAX MacAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Unique MAC Address assigned to the STA. " 
{ dotllOperationEntry 1 } 

dotllRTSThreshold OBJECT-TYPE 

SYNTAX INTEGER (0..2347) 
MAX-ACCESS read-write 
STATUS current 



MacAddress, 
INTEGER, 
INTEGER, 
INTEGER, 
INTEGER, 
INTEGER, 
INTEGER, 
DisplayString, 
DisplayString} 
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DESCRIPTION 

"This attribute shall indicate the number of octets in an MPDU, 
below which an RTS/CTS handshake shall not be performed. An 
RTS/CTS handshake shall be performed at the beginning of any 
frame exchange sequence where the MPDU is of type Data or 
Management, the MPDU has an individual address in the Address! 
field, and the length of the MPDU is greater than 
this threshold. (For additional details, refer to Table 21 in 
9.7.) Setting this attribute to be larger than the maximum 
MSDU size shall have the effect of turning off the RTS/CTS 
handshake for frames of Data or Management type transmitted by 
this STA. Setting this attribute to zero shall have the effect 
of turning on the RTS/CTS handshake for all frames of Data or 
Management type transmitted by this STA. The default value of 
this attribute shall be 2347." 

::= { dotllOperationEntry 2 } 

dotllShortRetryLimit OBJECT- TYPE 
SYNTAX INTEGER (1..255) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"This attribute shall indicate the maximum number of 
transmission attempts of a frame, the length of which is less 
than or equal to dot 11RTS Threshold, that shall be made before a 
failure condition is indicated. The default value of this 
attribute shall be 7." 

::= { dotllOperationEntry 3 } 

dotllLongRetryLimit OBJECT-TYPE 
SYNTAX INTEGER (1..255) 
MAX -ACCESS read- write 
STATUS current 
DESCRIPTION 

"This attribute shall indicate the maximum number of 
transmission attempts of a frame, the length of which is 
greater than dotllRTSThreshold, that shall be made before a 
failure condition is indicated. The default value of this 
attribute shall be 4 . " 

: : ~ { dotllOperationEntry 4 } 

do 1 1 1 Fragment a t ionThreshol d OBJECT - TYPE 
SYNTAX INTEGER (256.. 2346) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION " 

"This attribute shall specify the current maximum size, in 
octets, of the MPDU that may be delivered to the PHY. An MSDU 
shall be broken into fragments if its size exceeds the value 
of this attribute after adding MAC headers and trailers. An 
MSDU or MMPDU shall be fragmented when the resulting frame has 
an individual address in the Address 1 field, and the length of 
the frame is larger than this threshold. The default value 
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for this attribute shall be the lesser of 2346 or the 
aMPDUMaxLength of the attached PHY and shall never exceed the 
lesser of 2346 or the aMPDUMaxLength of the attached PHY. The 
value of this attribute shall never be less than 256." 

::= { dotllOperationEntry 5 } 

dot llMaxTransmitMSDUL if etime OBJECT- TYPE 
SYNTAX INTEGER (1. .4294967295) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The MaxTransmitMSDULifetime shall be the elapsed time in TU, 
after the initial transmission of an MSDU, after which further 
attempts to transmit the MSDU shall be terminated. The default 
value of this attribute shall be 512." 

::= { dotllOperationEntry 6 } 

dotllMaxReceiveLif etime OBJECT- TYPE 

SYNTAX INTEGER ( 1 4294967295 ) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"The MaxReceiveLif etime shall be the elapsed time in TU, "7 
after the initial reception of a fragmented MMPDU or MSDU, 
after which further attempts to reassemble the MMPDU or 
MSDU shall be terminated. The default value shall be 512." 
{ dotllOperationEntry 7 ) 

dotllManuf acturerlD OBJECT- TYPE 

SYNTAX Displays t ring (SIZE (0 .. 128) ) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The Manufacturer ID shall include, at a minimum, the name 
of the manufacturer. It may include additional 
information at the manufacturer's discretion. The default 
value of this attribute shall be null." 

{ dotllOperationEntry 8 ) 

dot 11 Product ID OBJECT -TYPE 

SYNTAX DisplayString (SIZE (0 128) ) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The Product ID shall include, at a minimum, an identifier 
that is unique to the manufacturer. It may include 
additional information at the manufacturer's discretion. 
The default value of this attribute shall be null," 

::= { dotllOperationEntry 9 } 

*++****************************************#*******+**+****+* ### ** +#%# 

-- * End of dotllOperationEntry TABLE 



Copyright © 1999 IEEE. All rights reserved. 



485 



ISO/IEC 8802-11: 1999(E) 

ANSI/IEEE Std 802. 1 1 , 1 999 Edition LOCAL AND METROPOLITAN AREA NETWORKS: WIRELESS LAN 

__ *** + ***** + ***** + ** + ★********** + + **#**** + ***** + *** * + * + ****★ + *★★*** + **** 

-- * dotllCounters TABLE 

__ **************************+*****#*#***#********+**+*+^ 

dotllCountersTable OBJECT -TYPE 

SYNTAX SEQUENCE OF DotllCountersEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Group containing attributes that are MAC counters. 
Implemented as a table to allow for multiple 
instantiations on an agent." 

: := { dotllmac 2 } 

dot 11 Counters Entry OBJECT- TYPE 

SYNTAX DotllCountersEntry 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllCountersEntry Table. 

if Index - Each 802.11 interface is represented by an 
ifEntry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index} 
::= { dotllCountersTable 1 } 

DotllCountersEntry ::= SEQUENCE { 

do tllTransmittedFragment Count Counter32 , 
dotllMulticastTransmittedFrameCount Counter32 , 

dotllFailedCount Counter32, 

dotllRetryCount Counter32, 

dotllMultipleRetryCount Counter32, 

dotllFrameDuplicateCount Counter32, 

dotllRTSSuccessCount Counter32, 

dotllRTSFailureCount Counter32, 

dotllACKFailureCount Counter32, 

do t 1 IRe ceivedF ragmen t Count Counter32 , 
dotllMulticastReceivedFrameCount Counter32 , 

dotllFCSErrorCount Counter32, 

dotllTransmittedFrameCount Counter32, 

dotllWEPUndecryptableCount Counter32 } 

dot llTransmittedFragment Count OBJECT- TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall be incremented for an acknowledged 
MPDU with an individual address in the address 1 field 
or an MPDU with a multicast address in the address 1 field 
of type Data or Management . " 

{ dotllCountersEntry 1 } 
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dot 1 lMul t i cas tTransmi t tedFrameCount OBJECT -TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment only when the multicast 
bit is set in the destination MAC address of a successfully 
transmitted MSDU. When operating as a STA in an ESS , where 
.these frames are directed to the AP, this implies having 
received an acknowledgment to all associated MPDUs . " 

: := { dotllCountersEntry 2 } 

dotllPailedCount OBJECT -TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when an MSDU is not 
transmitted successfully due to the number of 
transmit attempts exceeding either the 
dotllShortRetryLimit or dotllLongRetryLimit . " 

::= { dotllCountersEntry 3 } 

dotllRetryCount OBJECT -TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when an MSDU is successfully 
transmitted after one or more retransmissions." 
: : = { dotllCountersEntry 4 } 

dotllMultipleRetryCount OBJECT- TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when an MSDU is successfully 
transmitted after more than one retransmission." 

{ dotllCountersEntry 5 } 

dotUFrameDuplicateCount OBJECT- TYPE 
SYNTAX Counter32 
MAX -ACCESS rea'd-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when a frame is received 
that the Sequence Control field indicates is a 
duplicate. " 



{ dotllCountersEntry 6 } 
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dotllRTSSuccessCount OBJECT -TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when a CTS is received in 
response to an RTS . " 

::= { dotllCountersEntry 7 } 

dotllRTSFailureCount OBJECT- TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when a CTS is not received in 
response to an RTS . " 

::= { dotllCountersEntry 8 } 

dotllACKFailureCount OBJECT- TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when an ACK is not received 
when expected . " 

::= { dotllCountersEntry 9 } 

dot HReceivedFragment Count OBJECT- TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall be incremented for each successfully 
received MPDU of type Data or Management." 

: : = { dotllCountersEntry 10 } 

dotllMulticastReceivedFrameCount OBJECT -TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when a MSDU is received 
with the multicast bit set in the destination 
,MAC address . " 

: : = { dotllCountersEntry 11 } 

dotllFCSErrorCount OBJECT-TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
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STATUS current 
DESCRIPTION 

"This counter shall increment when an PCS error is 
detected in a received MPDU. " 

: : = { dotllCountersEntry 12 } 

dotllTransmittedFrameCount OBJECT- TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment for each successfully transmitted MSDU. " 

::= { dotllCountersEntry 13 } 

dotllWEPUndecryptableCount OBJECT -TYPE 
SYNTAX Counter32 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This counter shall increment when a frame is received with 
the WEP subfieid of the Frame Control field set to one and the 
WEPOn value for the key mapped to the TA's MAC address 
indicates that the frame should not have been encrypted or 
that frame is discarded due to the receiving STA not 
implementing the privacy option." 

::= { dotllCountersEntry 14 } 

******************************************************** ************** 

* End of dotllCountersEntry TABLE 

********************************************************************** 

- - * GroupAddresses TABLE 

__ ************************************************* ********************* 

dotllGroupAddressesTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Do tllGroupAddr esses Entry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"A conceptual table containing a set of MAC addresses 
identifying the multicast addresses for which this STA 
will receive frames. The default value of this attribute 
shall be null." 

: := { dotllmac 3 } 

dotllGroupAddressesEntry OBJECT-TYPE 

SYNTAX DotllGroupAddressesEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An Entry (conceptual row) in the Group Addresses Table. 
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if Index - Each 802.11 interface is represented by an 
if Entry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index, dot HGroupAddr esses Index} 

: := { dot HGroupAddresses Table 1 } 

DotllGroupAddressesEntry : := SEQUENCE { 

dotllGroupAddresses Index Integer32 , 

dotllAddress MacAddress, 

dotllGroupAddressesStatus RowStatus} 

dot HGroupAddresses Index OBJECT -TYPE 
SYNTAX Integer32 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"The auxiliary variable used to identify instances 

of the columnar objects in the Group Addresses Table." 

::= { dotllGroupAddressesEntry 1 } 

dotllAddress OBJECT-TYPE 
SYNTAX MacAddress 
MAX- ACCESS read- create 
STATUS current 
DESCRIPTION 

"MAC address identifying a multicast addresses 
from which this STA will receive frames." 
::= { dotllGroupAddressesEntry 2 } 

dotllGroupAddressesStatus OBJECT- TYPE 
SYNTAX RowStatus 
MAX -ACCESS read- create 
STATUS current 
DESCRIPTION 



"The status column used for creating, modifying, and 
deleting instances of the columnar objects in the Group 
Addresses Table . " 



DEFVAL {active} 

{ dotllGroupAddressesEntry 3 } 
__ ************+*+* + ***************★*#**** + #******** *★*★*** +++******★**★* 

-- * End of GroupAddress TABLE 

*************************************★****+***★★★*******+*****#*+***+# 

-- * Resource Type Attribute Templates 

★★*+**+***+** ★****+*★***#★*******+*********★***+****+**#**+*+*****+*** 

dotllResourceTypelDName OBJECT-TYPE 

SYNTAX DisplayString {SIZE (4)) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 
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"Contains the name of the Resource Type ID managed object. 

The attribute is read-only and always contains the value 

RTID. This attribute value shall not be used as a naming 
attribute for any other managed object class." 

REFERENCE " IEEE Std 802.1F-1993, A. 7" 
DEFVAL {"RTID") 
::= { dot llresAt tribute 1 } 

__ *****+*********************** 

-- * dotllResourcelnfo TABLE 

dotllResourcelnfoTabie OBJECT- TYPE 

SYNTAX SEQUENCE OF DotllResourcelnf oEntry 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Provides a means of indicating, in data readable from a 
managed object, information that identifies the source of 
the implementation." 

REFERENCE "IEEE Std 802. IF- 1993, A. 7" 
::= { dot llresAt tribute 2 } 

dotllResourcelnfoEntry OBJECT -TYPE 

SYNTAX DotllResourcelnfoEntry 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllResourcelnfo Table. 

if Index - Each 802.11 interface is represented by an 
ifEntry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index) 

::= { dotllResourcelnfoTabie 1 } 

DotllResourcelnfoEntry SEQUENCE { 
do 1 1 lmanu fa c ture rOUI 
dotllmanufacturerName 
dot 1 imanuf ac turerProductName 
do 1 1 lmanuf a c ture r Product Vers ion 



OCTET STRING, 
DisplayString, 
DisplayString, 
DisplayString) 



dot 1 lmanuf act urerOUI OBJECT- TYPE 

SYNTAX OCTET STRING (SIZE (3)) 
MAX -ACCESS read-only 
STATUS- current- ■ 
DESCRIPTION 

"Takes the value of an organizationally unique identifier." 

::= { dotllResourcelnfoEntry 1 } 

dotllmanufacturerName OBJECT- TYPE 

SYNTAX DisplayString (SIZE (0 . . 128) ) 
MAX -ACCESS read-only 
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STATUS current 
DESCRIPTION 

"A printable string used to identify the manufacturer of the 
resource. Maximum string length is 128 octets." 
: := ( dot 1 IResourcelnf cEntry 2 } 

dotllmanufacturerProductName OBJECT -TYPE 

SYNTAX D isp lays t ring (SIZE (0 . . 128 ) ) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"A printable string used to identify the manufacturer's product 
name of the resource. Maximum string length is 128 octets." 
::= { dotllResourcelnfoEntry 3 } 

dot llmanuf acturerProductVers ion OBJECT- TYPE 
SYNTAX DisplayString (SIZE (0 128) ) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"Printable string used to identify the manufacturer's product 
version of the resource. Maximum string length is 128 octets." 
::= { dotllResourcelnfoEntry 4 } 

******** ************************************************* ************* 

-- * End of dot HResource Info TABLE 

__ ************************************** ******************************** 

********************************************************************** 

-- * PHY Attribute Templates 

__ ********************************************************************** 

********************************************************************** 

-- * dotllPhyOperation TABLE 

********************************************************************** 

dotllPhyCperationTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotllPhyOperationEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"PHY level attributes concerned with 
operation. Implemented as a table indexed on 
if Index to allow for multiple instantiations on an 
Agent . " 

: : - { dotllphy 1 -} . 

dotllPhyOperationEntry OBJECT -TYPE 

SYNTAX DotllPhyOperationEntry 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllPhyOperation Table. 
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if Index - Each 802.11 interface is represented by an 
ifEntry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index} 
::= { dotllPhyOperationTable 1 } 

DotllPhyOperationEntry ::= SEQUENCE { 

do 1 1 1 PHYType INTEGER , 

dotllCurrentRegDomain Integer32, 
dotllTempType INTEGER 

} 

dot 11 PHYType OBJECT -TYPE 

SYNTAX INTEGER {fhss(D, dsss(2) / irbaseband (3 ) } 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This is an 8 -bit integer value that identifies the PHY type 
supported by the attached PLCP and PMD. Currently defined 
values and their corresponding PHY types are: 

FHSS 2.4 GHz = 01 , DSSS 2.4 GHz = 02, IR Baseband = 03" 

{ dotllPhyOperationEntry 1 } 

dotllCurrentRegDomain OBJECT -TYPE 
SYNTAX Integer32 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The current regulatory domain this instance of the PMD is 
supporting. This object corresponds to one of the 
RegDomains listed in do tllRegDoma ins Supported. " 

::= { dotllPhyOperationEntry 2 } 

dotllTempType OBJECT- TYPE 

SYNTAX INTEGER { tempTypel ( 1) , tempType2(2) } 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"There are different operating temperature requirements 
dependent on the anticipated environmental conditions. This 
attribute describes the current PHY's operating temperature 
range capability. Currently defined values and their 
corresponding temperature ranges are: 

Type r = X 1 01 ^-Commercial range of 0 to 40 degrees C, 

Type 2 = X ' 02 • -Industrial range of -30 to 70 degrees C." 

::= { dotllPhyOperationEntry 3 } 

._ **★*******************+********#****************+***★#****★#*#******#* 

-- * End of dotllPhyOperation TABLE 

******■**************************#*#*+**** + *******+*********** + * + *** + + * 
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****** + + **** + **#*★#★******★*****■************* + #* + ********** + * + + * + ***#* 

* , dotllPhyAntenna TABLE 
__ ******+★******★**+**+************++***+****#** **#**^ 

dotllPhyAntennaTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotllPhyAntenna En try 
MAX -ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Group of attributes for PhyAntenna. Implemented as a 
table indexed on if Index to allow for multiple instances on 
an agent . " 

: := { dotllphy 2} 

dotllPhyAntennaEntry OBJECT-TYPE 

SYNTAX DotllPhyAntennaEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllPhyAntenna Table. 

if Index - Each 802.11 interface is represented by an 
ifEntry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index} 

{ dotllPhyAntennaTable 1 } 

DotllPhyAntennaEntry ::= SEQUENCE { 
dot 1 lCur rentTxAn tenna 
dotllDiversitySupport 
dotllCurrentRxAntenna 

dotllCurrentTxAntenna OBJECT-TYPE 
SYNTAX Integer32 (1. .255) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The current antenna beino used to transmit . This value 
is one of the values appearing in dotl lSupportedTxAn tenna . 
This may be used by a management agent to control which 
antenna is used for transmission." 

: : = { dotllPhyAntennaEntry 1 } 

dotllDiversitySupport OBJECT -TYPE 

SYNTAX INTEGER { f ixedlist ( 1) , no t supported (2) , dynamic (3)} 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"This implementation's support for diversity, encoded as: 

X' 01' -diversity is available and is performed over the fixed 
list of antennas defined in dotllDiversitySelectionRx . 

X' 02' -diversity is not supported. 



Integer32, 
INTEGER, 
Integer32 } 
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X» 03 ' -diversity is supported and control of diversity is also 
available, in which case the attribute 

dotllDiversitySeiectionRx can be dynamically modified by the 
LME . " 

: : = { dotllPhyAntennaEntry 2 } 

dotllCurrentRxAntenna OBJECT-TYPE 
SYNTAX Integer32 (1. .255) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The current antenna being used to receive, if the 

dot 11 Divers itySupport indicates that diversity is not 

supported. The selected antenna shall be one of 

the antennae marked for receive in the dotllAntennasListTable. " 



: : = { dotllPhyAntennaEntry 3 } 

******★*******★********★*********★*#******#*#+*+*+*+#**#* 

* End of dotllPhyAntenna TABLE 

********************************************************************** 

__ ********************************************************************** 

-- * dotllPhyTxPower TABLE 

********************************************************* ************* 

dotllPhyTxPowerTable OBJECT -TYPE 

SYNTAX SEQUENCE OF DotllPhyTxPowerEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Group of attributes for dotllPhyTxPowerTable. Implemented 
as a table indexed on STA ID to allow for multiple 
instances on an Agent." 

: := { dotllphy 3} 

dotllPhyTxPowerEntry OBJECT- TYPE 

SYNTAX DotllPhyTxPowerEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllPhyTxPower Table. 

if Index - Each 802.11 interface is represented by an 
ifEntry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index} , 
::= { dotllPhyTxPowerTable 1 } 

DotllPhyiyPowerEntry ::=» SEQUENCE { 

dotllNumberSupportedPowerLevels INTEGER, 

dot HTxPowerLe veil INTEGER, 

do tllTx Power Level 2 INTEGER, 

do tllTx Power Level 3 INTEGER, 

do tllTx Power Level 4 . INTEGER, 

dotllTxPowerLevelS INTEGER, 
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do 1 1 lTx Powe r Le ve 1 6 
do 1 1 lTx Powe r Le ve 1 7 
do 1 1 lTx Po we r Le ve 1 8 
dotllCurrentTxPowerLevel 

dotllNumberSupportedPowerLeveis OBJECT- TYPE 
SYNTAX INTEGER ( 1 . . 8 ) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The number of power levels supported by the PMD. 
This attribute can have a value of 1 to 8." 
{ dotllPhyTxPowerEntry 1 } 

dot HTxPowerLe veil OBJECT- TYPE 

SYNTAX INTEGER (0.. 10000) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The transmit output power for LEVEL1 in mW. 

This is also the default power level." 
{ dotllPhyTxPowerEntry 2 } 

dotllTxPowerLevel2 OBJECT -TYPE 

SYNTAX INTEGER (0.. 10000) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The transmit output power for LEVEL2 in mW." 
::= { dotllPhyTxPowerEntry 3 } 

dotllTxPowerLeve!3 OBJECT- TYPE 

SYNTAX INTEGER (0.. 10000) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The transmit output power for LEVEL3 in mW." 
::= { dotllPhyTxPowerEntry 4 } 

dotllTxPowerLevel4 OBJECT- TYPE 

SYNTAX INTEGER (0.. 10000) 

STATUS current 
DESCRIPTION 

"The transmit output power for LEVEL4 in mW." 
::= { dotllPhyTxPowerEntry 5 } 

dotllTxPowerLevelS OBJECT- TYPE 

SYNTAX INTEGER (0.. 10000) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The transmit output power for LEVELS in mW. " 
::= { dotllPhyTxPowerEntry 6 } 

dotllTxPowerLevelS OBJECT- TYPE 

SYNTAX INTEGER (0.. 10000) 
MAX -ACCESS read-only 
STATUS current 



INTEGER, 
INTEGER, 
INTEGER, 
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DESCRIPTION 

"The transmit output power for LEVEL6 in mW." 
::= { dotllPhyTxPowerEntry 7 } 

dotllTxPowerLevei7 OBJECT- TYPE 

SYNTAX INTEGER (0.. 10000) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The transmit output power for LEVEL 7 in mW." 
: : = { dotllPhyTxPowerEntry 8 } 

dotllTxPowerLevel8 OBJECT- TYPE 

SYNTAX INTEGER (0.. 10000) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The transmit output power for LEVEL8 in mW. " 
::= { dotllPhyTxPowerEntry 9 } 

dotllCurrentTxPowerLevel OBJECT -TYPE 
SYNTAX INTEGER ( 1 . . 8 ) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The TxPowerLevel N currently being used to transmit data. 
Some PHYs also use this value to determine the receiver 
sensitivity requirements for CCA." 

: : = { dotllPhyTxPowerEntry 10 } 

****★**+**********+******★*★★*********************+*** ★***★*#****★**★★ 

-- * End of dotllPhyTxPower TABLE 

* dotllPhyFHSS TABLE 

*******************+**************+******************* 

dotllPhyFHSSTable OBJECT -TYPE 

SYNTAX SEQUENCE OF DotllPhyFHSSEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Group of attributes for dotllPhyFHSSTable . Implemented as a 
table indexed on STA ID to allow for multiple instances on 
an Agent . " 

: :=» { dotllphy 4 } 

dotllPhyFHSSEntry OBJECT -TYPE 

SYNTAX DotllPhyFHSSEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllPhyFHSS Table. 

if Index - Each 802.11 interface is represented by an 

if Entry. Interface tables in this MIB module are indexed 

by if Index. " 
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INDEX {if Index} 
::= { dotllPhyFHSSTable 1 } 



DotllPhyFHSSEntry SEQUENCE { 



dotllHopTime 

dot 1 1 Cur ren t Channe INurnb e r 

dotllMaxDwellTime 

dot 1 lCur rentDwel iTime 

dotllCurrentSet 

dot 11 Current Pat tern 

dot llCurrent Index 



INTEGER, 
INTEGER , 
INTEGER, 
INTEGER, 
INTEGER, 
INTEGER, 
INTEGER} 



dotllHopTime OBJECT- TYPE 

SYNTAX INTEGER (224) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 



{ dotllPhyFHSSEntry 1 } 

dotllCurrentChannelNumber OBJECT- TYPE 
SYNTAX INTEGER (0..99) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The current channel number of the frequency output by the RF 
synthesizer" 
: : = { dotllPhyFHSSEntry 2 } 

dotllMaxDwellTime OBJECT -TYPE 

SYNTAX INTEGER (1.. 65535) 

MAX -ACCESS read-only 

STATUS current 

DESCRIPTION 

"The maximum time in TU that the transmitter 
is permitted to operate on a single channel." 

{ dotllPhyFHSSEntry 3 } 

dot HCurrentDwel ITime OBJECT- TYPE 
SYNTAX INTEGER (1.. 65535) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 



"The current time in TU that the transmitter shall operate 
on a single channel, as set by the MAC. Default is 19 TU." 



::= { dotllPhyFHSSEntry 4 } 

dotllCurrentSet OBJECT- TYPE 

SYNTAX- INTEGER- (1..255) 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The current set of patterns the PHY 
LME is using to determine the hopping sequence. " 
::= { dotllPhyFHSSEntry 5 } 

dotllCurrentPattern OBJECT-TYPE 



"The time in microseconds for 
channel 2 to channel 80" 



the PMD to change from 



SYNTAX INTEGER (0. .255) 
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MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The current pattern the PHY LME is 

using to determine the hop sequence." 
::= { dotllPhyFHSSEntry 6 } 

dot HCur rent Index OBJECT-TYPE 

SYNTAX INTEGER (1..255) 
MAX -ACCESS read -write 
STATUS current 
DESCRIPTION 

"The current index value the PHY LME is using to determine 
the Cur rent ChannelNumber . " 

{ dotllPhyFHSSEntry 7 } 

++*********+**+**********+★**#*****+*★#***+#***★**###***##+##***#*#+** 

-- * End of dotllPhyFHSS TABLE 
__ 

-- * dotllPhyDSSSEntry TABLE 

************#**********#**#***♦********♦*****##*********+*****+******* 

dotllPhyDSSSTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotllPhyDSSSEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Entry of attributes for dotllPhyDSSSEntry. Implemented as a 
table indexed on if Index allow for multiple instances on 
an Agent . " 

: := { dotllphy 5 } 

dotllPhyDSSSEntry OBJECT-TYPE 

SYNTAX DotllPhyDSSSEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllPhyDSSSEntry Table. 

if Index - Each 802.11 interface is represented by an 

if Entry. Interface tables in this MIB module are indexed 

by if Index. " 

INDEX {if Index} 

{ dotllPhyDSSSTable 1 } 

DotllPhyDSSSEntry = SEQUENCE { 

dot HCur rent Channel INTEGER, 
dot llCCAModeSuppor ted INTEGER , 
dotllCurrentCCAMode INTEGER, 
dotllEDThreshold Integer32} 

dotllCurrentChannel OBJECT-TYPE 
SYNTAX INTEGER (1..14) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
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"The current operating frequency channel of the DSSS 
PHY. Valid channel numbers are as defined in 15.4.6.2" 
::= { dotllPhyDSSSEntry 1 } 

dotllCCAModeSupported OBJECT -TYPE 
SYNTAX INTEGER (1..7) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"dotllCCAModeSupported is a bit-significant value, representing all of the 
CCA modes supported by the PHY. Valid values are: 

energy detect only (ED_ONLY) =01, 
carrier sense only (CS__ONLY) = 02, 
carrier sense and energy detect (ED_and_CS)= 04 

or the logical sum of any of these values." 
::= { dotllPhyDSSSEntry 2 } 

dotllCurrentCCAMode OBJECT- TYPE 

SYNTAX INTEGER {edonly(l), csonly(2) , edandcs(4)} 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The current CCA method in operation. Valid values are: 
energy detect only (edonly) = 01, 
carrier sense only (csonly) « 02, 
carrier sense and energy detect (edandcs)= 04." 
::= { dotllPhyDSSSEntry 3 } 

dotllEDThreshold OBJECT- TYPE 
SYNTAX Integer32 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"The current Energy Detect Threshold being used by the DSSS PHY." 
::= { dotllPhyDSSSEntry 4 } 

**+**★**★★★ *********************************************************** 

* End of dotllPhyDSSSEntry TABLE 

********************************************++*+++*+++++++*++*++++**++ 

*************************************** ****************** 1titit i [ ^i rir i [if i rir i tit 

-- * dotllPhylR TABLE 

******************************************************** 

dot 1 1 Phy IRTabl e OBJECT - TYPE 

SYNTAX SEQUENCE OF Dot UPhylREntry 

MAX -ACCESS not -accessible 

STATUS current 

DESCRIPTION - . 

"Group of attributes for dotllPhylRTable . Implemented as a 
table indexed on if Index to allow for multiple instances on 
an Agent . " 

: := { dotllphy 6 } 

dotllPhylREntry OBJECT-TYPE 

SYNTAX DotllPhylREntry 
MAX -ACCESS not -accessible 
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STATUS current 
DESCRIPTION 

"An entry in the dotllPhylR Table. 

if Index - Each 802.11 interface is represented by an 
if Entry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {iflndex} 
::= { dotllPhylRTable 1 } 

DotllPhylREntry : : = SEQUENCE { 

dot 1 1 CCAWa t chdogTime rMax 
dot 1 1 CCAWa t chdogCoun tMax 
do 1 1 1 CCAWa t chdogTi me rMin 
dot HCCAWat chdogCoun tMin 

dotllCCAWatchdogTimerMax OBJECT -TYPE 
SYNTAX Integer32 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"This parameter, together with CCAWa tchdogCountMax, 
determines when energy detected in the channel can be 
ignored . " 

::= { dotllPhylREntry 1 } 

dot HCCAWa tchdogCountMax OBJECT- TYPE 
SYNTAX Integer32 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"This parameter, together with CCAWa t chdogTi me rMax , 
determines when energy detected in the channel can be 
ignored . n 

::= { dotllPhylREntry 2 } 

dotllCCAWatchdogTimerMin OBJECT-TYPE 
SYNTAX Integer32 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"The minimum value to which CCAWatchdogTimerMax can be 
set . " 

{ dotllPhylREntry 3 } 

dotllCCAWatchdogCountMin OBJECT -TYPE 
SYNTAX Integer32 
MAX -ACCESS read-write 
STATUS current 
DESCRIPTION 

"The minimum value to which CCAWatchdogCount can be set." 
{ dotllPhylREntry 4 } 

***********************************+******#***#**+******* +# ******** ## * 

-- * End of dotllPhylR TABLE 
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-- * dotllRegDomainsSupported TABLE 

__ ***************+*+****+****++**#+***********#***^ 

dotllRegDomainsSupportedTable OBJECT- TYPE 

SYNTAX SEQUENCE OF Dot HRegDoma ins Support En try 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"There are different operational requirements dependent on 
the regulatory domain. This attribute list describes the 
regulatory domains the PLCP and PMD support in this 
implementation. Currently defined values and their 
corresponding Regulatory Domains are: 

FCC (USA) = X'10', DOC (Canada) » X'20\ ETSI {most of 
Europe) = X'30', Spain «» X'31', France = X'32', MKK 
(Japan) = X'40* " 

: :« { dotllphy 7} 

dotllRegDomainsSupportEntry OBJECT -TYPE 

SYNTAX DotllRegDomainsSupportEntry 
MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the dot HRegDoma ins Support Table. 

if Index - Each 802.11 interface is represented by an 
if Entry. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index, dotllRegDomainsSupportlndex} 
::= { dotllRegDomainsSupportedTable 1 } 

DotllRegDomainsSupportEntry : := SEQUENCE { 

dotllRegDomainsSupportlndex Integer32, 
dotllRegDomainsSupportValue INTEGER} 

dotllRegDomainsSupportlndex OBJECT-TYPE 
SYNTAX Integer32 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"The auxiliary variable used to identify instances 
of the columnar objects in the RegDomainsSupport Table." 
::- { dotllRegDomainsSupportEntry 1 } 

dotllRegDomainsSupportValue OBJECT -TYPE 

SYNTAX INTEGER {fcc(16), doc (32) , etsi(48), spain (49), france 

(50), mkk (64)..} 

MAX -ACCESS read-only 

STATUS current 

DESCRIPTION 

"There are different operational requirements dependent on 
the regulatory domain. This attribute list describes the 
regulatory domains the PLCP and PMD support in this 
implementation. Currently defined values and their 
corresponding Regulatory Domains are: 
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FCC (USA) =» X'lCT, DOC (Canada) = X'20\ ETSI (most of 
Europe) « X'30', Spain = X*31', France « X'32\ MKK 
(Japan) » X'40' " 
{ do tllRegDoma ins Support En try 2 } 

****+********************************************************* ******** 

-- * End of dotllRegDomainsSupported TABLE 

*************+**************************************************+***+* 

*****************#***********************#*#***#+** ******************* 

-- * dotllAntennasList TABLE 

dotllAntennasListTable OBJECT -TYPE 

SYNTAX SEQUENCE OF DotllAntennasListEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"This table represents the list of antennae. An 
antenna can be marked to be capable of transmitting, 
receiving, and /or for participation in receive diversity. Each 
entry in this table represents a single antenna with 
its properties . The maximum number of antennae that can 
be contained in this table is 255." 
: := { dotllphy 8 } 

dotllAntennasListEntry OBJECT -TYPE 

SYNTAX DotllAntennasListEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An entry in the dotllAntennasListTable, 
representing the properties of a single antenna. 

if Index - Each 802.11 interface is represented by an 
if En try. Interface tables in this MIB module are indexed 
by if Index. " 
INDEX {if Index, dot HAntennaList Index} 
::- { dotllAntennasListTable 1 } 

DotllAntennasListEntry SEQUENCE { 

dot HAntennaList Index Integer32, 
dotllSupportedTxAntenna TruthValue, 
dot 11 Support edRxAntenna TruthValue, 
dotllDiversitySelectionRx TruthValue } 

dot HAntennaList Index OBJECT- TYPE 
SYNTAX Integer32 (1. .255) 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION - . 

"The unique index of an antenna which is 
used to identify the columnar, objects in 
the dotllAntennasList Table." 
: : = ( dotllAntennasListEntry 1 } 

dotllSupportedTxAntenna OBJECT- TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
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DESCRIPTION 

"When true, this object indicates that the 
antenna represented by dot 11 Antenna Index 
can be used as a transmit antenna." 

::- { dot HAntennasList Entry 2 } 

dotllSupportedRxAntenna OBJECT- TYPE 

SYNTAX TruthValue 

MAX -ACCESS read-write 

STATUS current 

DESCRIPTION 

"When true, this object indicates that the 
antenna represented by the do tllAntenna Index 
can be used as a receive antenna." 

::= { dot HAntennasList Entry 3 } 

dotllDiversitySelectionRx OBJECT-TYPE 

SYNTAX TruthValue 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"When true, this object indicates that the 
antenna represented by dot 11 Antenna Index can 
be used for receive diversity. This object 
may only be true if the antenna can be used 
as a receive antenna, as indicated by 
dotllSupportedRxAntenna. " 

::= { dotllAntennasListEntry 4 } 

__ ************************************************* 

-- * End of dot HAntennasList TABLE 

__ *********************************************************** ir +i litir i r +ir it i l + 



_ _ ****************************************************** ***** ir i fit1[irir1rir i fir i r 

-- * SupportedDataRatesTx TABLE 

__ *******************************************************+*+*+++*++*+++* 

dotllSupportedDataRatesTxTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotlXSupportedDataRatesTxEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"The Transmit bit rates supported by the PLCP and PMD, 
represented by a count from X'02-X'7f, corresponding to data 
rates in increments of 500Kb/s from 1 Mbit/s to 63.5 Mbit/s subject 
to limitations of each individual PHY." 

: { dotllphy 9 } 

dotllSupportedDataRatesTxEntry OBJECT -TYPE 

SYNTAX DotllSupportedDataRatesTxEntry 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"An Entry (conceptual row) in the dot 11 SupportedDataRatesTx 
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if Index - Each 802.11 interface is represented by an 

if Entry. Interface tables in this MIB module are indexed 

by if Index. " 

INDEX {if Index, dotllSupportedDataRatesT^Index} 

::= { dotllSupportedDataRatesTxTable 1 } 

DotllSupportedDataRatesTxEntry = SEQUENCE { 

dotllSupportedDataRatesTxIndex Integer32, 
dotllSupportedDataRatesTxVaiue Integer 3 2 } 

dotllSupportedDataRatesTxIndex OBJECT -TYPE 
SYNTAX Integer3 2 ( 1 . . 8 ) 
MAX- ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Index object which identifies which data rate to access. 
Range is 1 . . 8 . " 

::= { dotllSupportedDataRatesTxEntry 1 } 

dotllSupportedDataRatesTxVaiue OBJECT -TYPE 
SYNTAX Integer32 (2.. 127) 
MAX- ACCESS read-only 
STATUS current 
DESCRIPTION 

"The Transmit bit rates supported by the PLCP and PMD, 
represented by a count from X'02-X'7f, corresponding to data 
rates in increments of 500Kb/s from 1 Mbit/s to 63.5 Mbit/s subject 
to limitations of each individual PHY." 

::= { dotllSupportedDataRatesTxEntry 2 } 

★****★ + **★**★****★★# + ********# ******★************★********** + ***** + *** 

-- * End of dotllSupportedDataRatesTx TABLE 



* SupportedDataRatesRx TABLE 
__ ***************** 

dotllSupportedDataRatesRxTable OBJECT -TYPE 

SYNTAX SEQUENCE OF DotllSupportedDataRatesRxEntry 

MAX -ACCESS not-accessible 

STATUS current 

DESCRIPTION - . 

"The receive bit rates supported by the PLCP and PMD, 
represented by a count from X'002-X'7f, corresponding to data 
rates in increments of 500Kb/s from 1 Mbit/s to 63.5 Mbit/s." 

: := { dotllphy 10 } 

dotllSupportedDataRatesRxEntry OBJECT -TYPE 

SYNTAX DotllSupportedDataRatesRxEntry 
MAX -ACCESS not -accessible 
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STATUS current 
DESCRIPTION 

"An Entry (conceptual row) in the 
dotllSupportedDataRatesRx Table. 

if Index - Each 802.11 interface is represented by an 

if Entry. Interface tables in this MIB module are indexed 

by if Index. " 

INDEX {if Index, dotllSupportedDataRatesRxIndex} 

::= { dotllSupportedDataRatesRxTable 1 } 

DotllSupportedDataRatesRxEntry ::= SEQUENCE { 

dotllSupportedDataRatesRxIndex Integer32 , 
dotllSupportedDataRatesRx Value Integer32 } 
# 

dotllSupportedDataRatesRxIndex OBJECT -TYPE 
SYNTAX Integer32 (1..8) 
MAX -ACCESS not -accessible 
STATUS current 
DESCRIPTION 

"Index object which identifies which data rate to access. 
Range is 1. . 8. " 
::= { dotllSupportedDataRatesRxEntry 1 } 

dotllSupportedDataRatesRxValue OBJECT -TYPE 
SYNTAX Integer3 2 (2.. 127) 
MAX -ACCESS read-only 
STATUS current 
DESCRIPTION 

"The receive bit rates supported by the PLCP and PMD, 
represented by a count from X'02-X'7f, corresponding to data 
rates in increments of 500 Kb/s from 1 Mbit/s to 63.5 Mbit/s." 
::= { dotllSupportedDataRatesRxEntry 2 } 

********************************************************************** 

* End of dotllSupportedDataRatesRx TABLE 

********************************************************************** 

__ ********************************************************************** 

-- * conformance information 

__ ******************************************************** 

dotllConformance OBJECT IDENTIFIER : := { ieee802dotll 5 } 
dotllGroups OBJECT IDENTIFIER : : = { dotllConf ormance 1 } 
dotllCompliances OBJECT IDENTIFIER ::= { dotllConformance 2 } 

********************************************************************** 

-- * compliance statements 

********************************************************************** 

dotllCompliance MODULE- COMPLIANCE 
STATUS current 
DESCRIPTION 

"The compliance statement for SNMPv2 entities 
that implement the IEEE 802.11 MIB." 

MODULE -- this module 
MANDATORY -GROUPS { 
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dotllSMTbase2, 

dotllMACbase, dot HCountersG roup, 
dot HSmtAuthent icationAigorithms , 

dotllResourceTypelD, dot UPhyOperationCompiianceG roup } 

GROUP dotllPhyDSSSCompiianceGroup 
DESCRIPTION 

"Implementation of this group is required when object 
dotllPHYType has the value of dsss . This group is 
mutually exclusive with the groups dotllPhylRComplianceGroup and 
dotllPhyFHSSComplianceGroup. " 

GROUP dotllPhylRComplianceGroup 
DESCRIPTION 

"Implementation of this group is required when object 
dotllPHYType has the value of irbaseband. This group is 
mutually exclusive with the groups dotllPhyDSSSCompiianceGroup and 
dotllPhyFHSSComplianceGroup. " 

GROUP dotllPhyFHSSComplianceGroup 
DESCRIPTION 

"Implementation of this group is required when object 
dotllPHYType has the value of f hss . This group is 
mutually exclusive with the groups dotllFhyDSSSCompiianceGroup and 
dotllPhylRComplianceGroup 

-- OPTIONAL -GROUPS { dotllSMTprivacy, dotllMACStatistics, 

dot llPhyAntennaComplianceG roup, dotllPhyTxPowerComplianceGroup, 

dot 1 lPhyRegDomainsSupportG roup , 

dot UPhyAntennasListG roup, dotllPhyRateGroup } 

{ dotllCompliances 1 } 

*********★******************+**#***#***********+ *******#***★******★*** 

-- * Groups - units of conformance 

******★***★*★***************★*###* + ************** a-******************** 

dotllSMTbase OBJECT -GROUP 

OBJECTS { dotllStationID, dotllMediumOccupancyLimit , 
dotllCFPollable, 
dotllCFPPeriod, 
dot HCFPMaxDurat ion , 
dotllAuthenticationResponseTimeOut, 
dot llPrivacyOpt ion Implemented, 
dot 1 1 PowerManagement Mode , 
dotllDesiredSSID, dotllDesiredBSSType, 
dotllOperationalRateSet , 
dot llBeaconPeriod , dot 1 lDTIMPer iod , 
dot llAssociat ionResponseTimeOut 

} 

STATUS deprecated 
DESCRIPTION 

"The SMT object class provides the necessary support at the 
STA to manage the processes in the STA such that the STA may 
work cooperatively as a part of an IEEE 802.11 network." 
{dotllGroupS 1 ) 
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dotllSMTprivacy OBJECT-GROUP 

OBJECTS { dot 11 Privacy Invoked, 

dot llWEPKeyMappingLength, dotl lExdudeUnencrypted , 
dotllWEPICVErrorCount , dotllWEPExdudedCount , 
dot HWEPDe fault Key ID, 
dot 11 WE PDe fault KeyVa lue , 
dotllWEPKeyMappingWEPOn, 

dotllWEPKeyMappingValue , dotllWEPKeyMappingAddress, 
dotllWEPKeyMappingStatus } 

STATUS current 
DESCRIPTION 

"The SMTPrivacy package is a set of attributes that shall be 
present if WEP is implemented in the STA . " 
::= {dotllGroups 2 } 

dotllMACbase OBJECT -GROUP 

OBJECTS { dotllMACAddress, dotllAddress, 
dot 1 lGroupAddres sesS ta tus , 
dotllRTSThreshoid, dotllShortRetryLimit , 
dotllLongRetryLimit, dot 11 Fragment at ionThreshold, 
dot 1 IMaxTransmi tMSDULi f e t ime , 
dotllMaxReceiveLifetime, dotllManufacturerlD, 
dotllProductID 

} 

STATUS current 
DESCRIPTION 

"The MAC object class provides the necessary support for the 
access control, generation, and verification of frame check 
sequences, and proper delivery of valid data to upper 
layers . " 
: :- {dotllGroups 3 } 

dotllMACStatistics OBJECT -GROUP 

OBJECTS { dotllRetryCount, dotllMultipleRetryCount, 
do 1 1 IRTSSuc c es sCoun t , do 1 1 1RTS Fa i 1 ureCount , 
dotllACKFailureCount, dotllFrameDuplicateCount } 

STATUS current 
DESCRIPTION 

"The MACStatistics package provides extended statistical 
information on the operation of the MAC. This 
package is completely optional." 
: := {dotllGroups 4 } 

dotllResourceTypelD OBJECT -GROUP 

OBJECTS { dotllResourceTypelDName, dotllmanufacturerOUI, 

dotllmanufacturerName, dotllmanufacturerProductName, 

dotllrnanufacturerProductVersion } 
STATUS current 
DESCRIPTION 

"Attributes used to identify a STA, its manufacturer, 
and various product names and versions." 

: {dotllGroups 5 } 
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dot llSmtAu then ticationAlgorithms OBJECT -GROUP 
OBJECTS { dotllAuthenticationAlgorithm, 

dotllAuthenticationAlgorithmsEnabie } 
STATUS current 
DESCRIPTION 

"Authentication Algorithm Table." 
{dotllGroups 6 } 



dot 11-PhyOperat ionComplianceGroup OBJECT -GROUP 

OBJECTS { dotllPHYType, dotllCurrentRegDomain, dotllTempType ) 

STATUS current 

DESCRIPTION 

" PHY layer operations attributes." 
::= { dotllGroups 7 } 

do 1 1 1 PhyAn t ennaCompl ianceG roup OB JECT -GROUP 

OBJECTS {dotllCurrentTxAntenna, dot HDi vers itySupport, 

dotllCurrentRxAntenna } 
STATUS current 
DESCRIPTION 

"Attributes for Data Rates for IEEE 802.11." 
{ dotllGroups 8 } 

do 1 1 1 PhyTxPowe rComp 1 ianceG roup OB JECT -GROUP 

OBJECTS {dotllNumberSupportedPowerLevels, dotllTxPowerLeveil, 
dotllTxPowerLevel2, dotllTxPowerLevelS, dotin*PowerLevel4', 
dotllTxPowerLevelB, dotllT*PowerLevel6, dotllTxPowerLevel?, 
dotllTx Power Levels, dot 11 Current TxPower Level } 

STATUS current 

DESCRIPTION 

"Attributes for Control and Management of transmit power." 
::= { dotllGroups 9 } 

dot 11 PhyFHSSCompl ianceG roup OBJECT - GROUP 

OBJECTS {dotllHopTime, dotllCurrentChannelNurnber, dotllMaxDwellTime, 
dotllCurrentDwellTime, dotllCurrentSet, dotllCurrentPattern, 
dotllCurrentlndex} 

STATUS current 

DESCRIPTION 

"Attributes that configure the Frequency Hopping for IEEE 
802.11. " 

{ dotllGroups 10 } 

dotllPhyDSSSComplianceGroup OBJECT-GROUP 

OBJECTS { do t llCurr en t Channel, dotllCCAModeSupported, 

dotllCurrentCCAMode, dotllEDThreshold) 
STATUS current 
DESCRIPTION 

"Attributes that configure the DSSS for IEEE 802.11." 
: := { dotllGroups 11 } 

dot 1 1 Phy IRCompl ianceGroup OB JECT- GROUP 

OBJECTS {dotllCCAWatchdogTimerMax, dotllCCAWatchdogCountMax, 
dotllCCAWatchdogTimerMin, dotllCCAWatchdogCountMin} 
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STATUS current 
DESCRIPTION 

"Attributes that configure the baseband IR for IEEE 802.11.' 
: := { dotllGroups 12 } 

do 1 1 1 PhyRegDoma ins Suppo r tGroup OBJECT - GROUP 

OBJECTS { dotllRegDomainsSupportValue} 

STATUS current 

DESCRIPTION 

"Attributes that specify the supported Regulation Domains." 
: := { dotllGroups 13} 

do 1 1 1 PhyAn t ennasL i s tGroup OBJECT - GROUP 

OBJECTS { dotllSupportedTxAntenna, 

dotllSupportedRxAntenna, dotllDiversitySelectionRx } 
STATUS current 
DESCRIPTION 

"Attributes that specify the supported Regulation Domains." 
: := { dotllGroups 14 } 

dotllPhyRateGroup OBJECT-GROUP 

OBJECTS { do 1 1 1 Support edDa t aRa te sTxVa lue , 
do t 1 lSuppo rt edDa t aRa t esRxValue 

} 

STATUS current 
DESCRIPTION 

"Attributes for Data Rates for IEEE 802.11." 
: :=: { dotllGroups 15 } 



dotllCountersGroup OBJECT - GROUP 
OBJECTS { 

dotllTransmittedFragmentCount , 
dotllMulticastTransmittedFrameCount , 
dotllFailedCount , dotllReceivedFragmentCount , 
dotllMulticastReceivedFrameCount 
dot 1 lFCSErrorCount , 

dotllWEPUndecryptableCount , 

dotllTransmittedFrameCount } 

STATUS current 
DESCRI PTIOM 

"Attributes from the dotllCountersGroup that are not described 
in the dotllMACStatistics group. These objects are 
mandatory. " 
::= {dotllGroups 16 } 

dotllNotificationGroup NOTIF I CATION- GROUP 
NOTIFICATIONS { dotllDisassociate , 

dot 1 IDeauthent i ca te , 
"dotllAuthenticateFail } 

STATUS current 
DESCRIPTION 

"IEEE 802.11 notifications" 
::= { dotllGroups 17 } 



dotllSMTbase2 OBJECT-GROUP 
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OBJECTS { dotllMediumOccupancyLimit, 
dotllCFPoIIabie, 
dotllCFPPeriod, 
dot HCFPMaxDurat ion , 
dot 1 lAuthent i ca t ionResponseTimeOut , 
dot UPrivacyOpt ion Implemented, 
dot UPowerManagementMode , 
dotllDesiredSSID, dotllDesiredBSSType, 
dotllOperationaiRateSet , 
dotllBeaconPeriod, dotllDTIMPeriod, 

dot llAssociat ionResponseTimeOut, 1 

dotllDisassociateReason, 

dotllDisassociateStation r 

dotllDeauthenticateReason, 

dotllDeauthenticateStation, 

dotllAuthenticateFailStatus, 

dotllAuthenticateFailStation 

} 

STATUS current 
DESCRIPTION 

"The SMTbase2 object class provides the necessary support at the 
STA to manage the processes in the STA such that the STA may 
work cooperatively as a part of an IEEE 802.11 network." 
::= {dotllGroups 18 } 

__ ************************************************* ********************* 

-- * End of 80211 MIB 

********************************************************************** 

END 
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